Just found the boot_overdrive_table curve voltags need also be updated.
Could you help to update them also?
I think the code pieces like below should work.
static int navi10_set_default_od_settings(struct smu_context *smu, bool
initialize) {
- OverDriveTable_t *od_table;
+
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, January 29, 2020 3:47 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 2/2] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_latency
Only send non-0 clocks
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Thursday, January 30, 2020 2:02 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH 3/3] drm/amdgpu/smu10: fix smu10_get_clock_by_type_with_voltage
Cull out 0 clocks to
Reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, February 4, 2020 4:36 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: fetch default VDDC curve voltages (v2)
Ask the SMU for the default VDDC curve
Ping?
On Tue, Jan 28, 2020 at 2:47 PM Alex Deucher wrote:
>
> Only send non-0 clocks to DC for validation. This mirrors
> what the windows driver does.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
> Signed-off-by: Alex Deucher
> ---
>
Ping?
On Wed, Jan 29, 2020 at 1:01 PM Alex Deucher wrote:
>
> Cull out 0 clocks to avoid a warning in DC.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/963
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/smu10_hwmgr.c | 8 +---
> 1 file changed, 5
Ping?
On Fri, Jan 10, 2020 at 3:11 PM Alex Deucher wrote:
>
> It looks like we should be reducing the group size when we don't
> have a plane rather than when we do.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
> Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is
> On Feb 3, 2020, at 11:16 AM, Christian König wrote:
>
> Am 03.02.20 um 17:18 schrieb Tianlin Li:
>> Right now several architectures allow their set_memory_*() family of
>> functions to fail,
>
> Oh, that is a detail I previously didn't recognized. Which architectures are
> that?
>
> Cause
Hi Jerry,
First of all, thanks for your patch. You can see some comments inline,
just simple things.
On 01/31, Jerry (Fangzhi) Zuo wrote:
> Unlike DP 1.2 edid corruption test, DP 1.4 requires to calculate
> real CRC value of the last edid data block, and write it back.
> Current edid CRC
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> VBLANK callbacks in struct drm_driver are deprecated in favor of
> their equivalents in struct drm_crtc_funcs. Convert amdgpu over.
>
> v2:
> * don't wrap existing functions; change signature instead
>
> Signed-off-by: Thomas
On Thu, Jan 23, 2020 at 9:00 AM Thomas Zimmermann wrote:
>
> The callback struct drm_driver.get_scanout_position() is deprecated in
> favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert
> amdgpu over.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Alex Deucher
> ---
>
Ask the SMU for the default VDDC curve voltage values. This
properly reports the VDDC values in the OD interface.
v2: only update if the original values are 0
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c |
Ask the SMU for the default VDDC curve voltage values. This
properly reports the VDDC values in the OD interface.
Bug: https://gitlab.freedesktop.org/drm/amd/issues/1020
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/navi10_ppt.c | 44 +-
1 file changed, 43
Provide compute queues information in sysfs under /sys/class/kfd/kfd/proc.
The format is /sys/class/kfd/kfd/proc//queues//XX where
XX are size, type, and gpuid three files to represent queue size, queue
type, and the GPU this queue uses. folder and files underneath
are generated when a queue is
Am 03.02.20 um 17:18 schrieb Tianlin Li:
Right now several architectures allow their set_memory_*() family of
functions to fail,
Oh, that is a detail I previously didn't recognized. Which architectures
are that?
Cause the RS400/480, RS690 and RS740 which are affected by this are
integrated
Right now several architectures allow their set_memory_*() family of
functions to fail, but callers may not be checking the return values.
If set_memory_*() returns with an error, call-site assumptions may be
infact wrong to assume that it would either succeed or not succeed at
all. Ideally,
Am 03.02.20 um 10:06 schrieb Dan Carpenter:
On Sun, Feb 02, 2020 at 02:19:18PM +0100, Daniel Vetter wrote:
On Fri, Jan 31, 2020 at 11:28 PM syzbot
wrote:
Hello,
syzbot found the following crash on:
HEAD commit:39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
git tree:
On Sun, Feb 02, 2020 at 02:19:18PM +0100, Daniel Vetter wrote:
> On Fri, Jan 31, 2020 at 11:28 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:39bed42d Merge tag 'for-linus-hmm' of git://git.kernel.org..
> > git tree: upstream
> >
We are working with new laptops that have the Ryzen 7 4700U.
It fails to launch X so I can only access via the virtual terminal.
I tried with the latest mainline kernel and kernel from
https://cgit.freedesktop.org/~agd5f/linux but no luck. I also boot
the kernel with parameter
During normal usage, especially if jobs are started and stopped in rapid
succession, the kernel log is filled with messages like this:
[38732.522910] Restoring PASID 0x8003 queues
[38732.666767] Evicting PASID 0x8003 queues
[38732.714074] Restoring PASID 0x8003 queues
[38732.815633] Evicting
Joe Perches writes:
> On Sun, 2020-02-02 at 00:11 +0100, Julian Sax wrote:
>> During normal usage, especially if jobs are started and stopped in rapid
>> succession, the kernel log is filled with messages like this:
>>
>> [38732.522910] Restoring PASID 0x8003 queues
>> [38732.666767] Evicting
During normal usage, especially if jobs are started and stopped in rapid
succession, the kernel log is filled with messages like this:
[38732.522910] Restoring PASID 0x8003 queues
[38732.666767] Evicting PASID 0x8003 queues
[38732.714074] Restoring PASID 0x8003 queues
[38732.815633] Evicting
On Sun, 2020-02-02 at 00:11 +0100, Julian Sax wrote:
> During normal usage, especially if jobs are started and stopped in rapid
> succession, the kernel log is filled with messages like this:
>
> [38732.522910] Restoring PASID 0x8003 queues
> [38732.666767] Evicting PASID 0x8003 queues
>
Fixes coccicheck warnings:
./drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c:2198:40-45: WARNING:
conversion to bool not needed here
./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:2884:68-73: WARNING:
conversion to bool not needed here
Signed-off-by: Chen Zhou
---
syzbot has found a reproducer for the following crash on:
HEAD commit:94f2630b Merge tag '5.6-rc-small-smb3-fix-for-stable' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11d6c776e0
kernel config:
25 matches
Mail list logo
