[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
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
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
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
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
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
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
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
[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
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
[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,
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
[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
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
[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
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
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
---
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
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
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
>>> 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
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
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:
On Thu, 2020-06-25 at 10:14 +0300, Maxim Levitsky wrote:
> Hi,
>
> I recently tried to connect my TV and WX4100 via two different DP->HDMI
> dongles.
> One of them makes my main monitor to go dark, and system to lockup (I haven't
> yet debugged this futher), and the other one seems to work,
>
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Sheng, Wenhui
Sent: Monday, June 29, 2020 14:08
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Sheng, Wenhui
Subject: [PATCH] drm/amdgpu: correct discovery_tmr_size init val
From: Wenhui
From: Wenhui Sheng
The legacy way to initialize discovery_tmr_size
is using DISCOVERY_TMR_SIZE, while after we reduce
DISCOVERY_TMR_SIZE from 64KB to 4KB, variable
discovery_tmr_size is also reduced to 4KB, this is not
correct, it still should be 64KB, discovery_tmr_size
will be used to
31 matches
Mail list logo
