This allows kernel mapped pages like the PDB and PTB to be
read via the iomem debugfs when there is no vram in the system.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu
These were requested by a UMR user for debugging purposes.
Signed-off-by: Tom St Denis
---
.../asic_reg/smuio/smuio_10_0_2_offset.h | 102 ++
.../asic_reg/smuio/smuio_10_0_2_sh_mask.h | 184 ++
2 files changed, 286 insertions(+)
create mode 100644
drivers/gpu
Hello all,
I've pushed out the Remote UMR branch for people to take a look at before I
merge it into main in a couple of weeks.
https://gitlab.freedesktop.org/tomstdenis/umr/-/commit/712acea483cbbacb35cb1a431dea501f041065ff
This feature allows running the privileged side of umr elsewhere
Checked against database, copied from GC 9.4.2 header.
Signed-off-by: Tom St Denis
---
.../include/asic_reg/gc/gc_10_1_0_offset.h| 4 ++
.../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 54 +++
.../include/asic_reg/gc/gc_10_3_0_offset.h| 4 ++
.../include/asic_reg/gc
From: Colin Lee
Newer generations of hardware encode the PDE
and PTE bitfields differently. This patch
refactors this decoding and printing.
gfx11 hardware introduces TFS addressing relative
to PDE0 which this patch also enables.
Signed-off-by: Tom St Denis
---
src/app/server.c| 2
Currently our debugfs bank selection logic only
supports a single GC instance. This updates the functions
amdgpu_gfx_select_se_sh() and amdgpu_gfx_select_me_pipe_q()
to support a GC instance parameter and ultimately a GC
instance selection via the IOCTL to debugfs.
Signed-off-by: Tom St Denis
These are used by umr to sort the hive nodes since the kernel
initializes the nodes in order of bus enumeration not XGMI hive
enumeration.
Signed-off-by: Tom St Denis
---
.../drm/amd/include/asic_reg/mmhub/mmhub_9_4_1_offset.h | 4
.../drm/amd/include/asic_reg/mmhub/mmhub_9_4_1_sh_mask.h
The TCC_DISABLE registers were not included in the 10.3 headers and
instead just placed directly in the gfx_v10_0.c source. This patch
adds them to the headers so tools like umr can scan them and support them.
Signed-off-by: Tom St Denis
---
.../gpu/drm/amd/include/asic_reg/gc
The revision was not changed to 5 from 4. Also since
this was missed I took the opportunity to add future
upper 64-bits of PG flags as well so we don't need to
bump it again when that comes.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 ---
1 file changed
Needed by umr to detect if ip discovered ASIC is an APU or not.
(v2): Remove asic type from packet it's not strictly needed
(v3): Correct comment
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Needed by umr to detect if ip discovered ASIC is an APU or not.
(v2): Remove asic type from packet it's not strictly needed
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd
Needed by umr to detect if ip discovered ASIC is an APU or not.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu
Thanks, if we don't end up dropping this patchset I'll incorporate your
suggestions into a v3.
Tom
On Wed, Jan 26, 2022 at 12:36 AM Limonciello, Mario <
mario.limoncie...@amd.com> wrote:
> A few suggestion ideas inline.
>
> On 1/25/2022 12:18, Tom St Denis wrote:
> &g
for buffer size and fix alignment in amdgpu.h
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 79 ++-
2 files changed, 79 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
{0} v3.0.0: 01a0 02409c00
DF{0} v3.0.0: 7000 0240b800
DFX{0} v4.1.0: 0580 02409400
DFX_DAP{0} v2.0.0: 05a0 00b8 0240c400
DMU{0} v2.0.2: 0012 00c0 34c0 9000 02403c00
FUSE{0} v11.0.0: 00017400 02401400
GC{0} v10.1.10: 1260 a000 02402c00
Signed-off-by: Tom St
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to
MMIO registers. It didn't support registers beyond the BAR mapped MMIO
space. This adds pcie indirect write support.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +++-
1 file changed, 3
Move dpcs headers from asic_reg/dcn to asic_reg/dpcs.
Update various .c files to include new path.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c | 4 ++--
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_resource.c | 4 ++--
drivers/gpu/drm/amd
The commit 9b716ef1501b2e62181073493dc1c7a17140bd21 added the offset
header but didn't add the masks. This adds the masks based on what
was selected for the offsets.
Signed-off-by: Tom St Denis
---
.../include/asic_reg/mp/mp_11_0_8_sh_mask.h | 355 ++
1 file changed, 355
-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 150
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_umr.h | 51 +++
3 files changed, 201 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm
be.
(v2): Move read/write to .read/.write, fix style, add comment
for IOCTL data structure
(v3): C style comments
(v4): use u32 in struct and remove offset variable
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 158
drivers/gpu/drm/amd
md/amdgpu/amdgpu.o -C amdgpu_debugfs_regs2_iocdata
>
> It has a rather nifty output with padding holes, byte addresses, cache
> lines etc for your structure.
>
> Christian.
>
> Am 25.08.21 um 13:04 schrieb Tom St Denis:
>
> I tested it by forcing bit patterns into the ioctl da
just make sure that you don't have any hidden
> padding.
>
> Nirmoy had a tool to double check for paddings which I once more forgot
> the name of.
>
> Christian.
>
> Am 25.08.21 um 12:40 schrieb Tom St Denis:
>
> The struct works as is but I'll change them to u32.
in a bit this morning
Tom
On Wed, Aug 25, 2021 at 2:35 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
>
>
> Am 24.08.21 um 15:36 schrieb Tom St Denis:
> > This new debugfs interface uses an IOCTL interface in order to pass
> > along state informat
be.
(v2): Move read/write to .read/.write, fix style, add comment
for IOCTL data structure
(v3): C style comments
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 162
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 32
2 files changed
be.
(v2): Move read/write to .read/.write, fix style, add comment
for IOCTL data structure
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 162
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 32
2 files changed, 194 insertions
hehehe I just moved it to uapi... No worries, you're the maintainer, I'll
move it back before posting v2.
Cheers,
Tom
On Tue, Aug 24, 2021 at 9:22 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am 24.08.21 um 14:42 schrieb Tom St Denis:
>
> The IOCTL data is
er to pass
> >> along state information like SRBM and GRBM bank switching. This
> >> new interface also allows a full 32-bit MMIO address range which
> >> the previous didn't. With this new design we have room to grow
> >> the flexibility of the file as need be.
> >&
be.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 177
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.h | 32
2 files changed, 209 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu
Signed-off-by: Tom St Denis
---
.../gpu/drm/amd/include/asic_reg/gc/gc_10_3_0_offset.h | 6 ++
.../gpu/drm/amd/include/asic_reg/gc/gc_10_3_0_sh_mask.h | 9 +
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_3_0_offset.h
b/drivers/gpu
This is why I advocated for the sysfs output to be either standard packed
or serialized. It was a hack as it is anyways.
On Mon, Feb 22, 2021 at 4:46 PM Alex Deucher wrote:
> On Sun, Feb 21, 2021 at 11:03 PM Evan Quan wrote:
> >
> > To make sure they are naturally aligned.
> >
> > Change-Id:
Hi,
This update doesn't match the gc_9_0_0 headers from the drm-next branch as
such cannot be made to umr. You need to first update the kernel headers
and then we circle back to umr.
Tom
On Tue, Jan 26, 2021 at 12:43 AM wrote:
> From: Guo Lei
>
> sync form drm-next
>
> Signed-off-by: Guo
t; command.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 68 +++--
1 file changed, 37 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 41ca13f0acd5..dd9df90a3
For whatever reason when I download this message and try to add it with
"git am" it says the patch is empty.
Can you attach the patch as an attachment please?
Thanks,
Tom
On Mon, Oct 26, 2020 at 11:29 PM Quan, Evan wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Reviewed-by:
This register was requested for umr debugging support.
Signed-off-by: Tom St Denis
---
.../amd/include/asic_reg/uvd/uvd_7_0_offset.h | 3 +++
.../include/asic_reg/uvd/uvd_7_0_sh_mask.h| 20 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/include
Thanks, applied!
In future patches can you please add a Signed-off line (e.g. use "-s" with
git when forming the commit).
Tom
On Thu, Aug 27, 2020 at 9:43 PM 张二东 wrote:
> Yes, you are right. New patch is in attachment.
>
> thanks.
>
>
>
>
>
>
>
isn't a better fix to simply delete the line? The print seems redundant to
me.
Tom
On Thu, Aug 27, 2020 at 9:27 AM 张二东 wrote:
>
>
>
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
>
Sorry I missed this. I've applied it (with whitespace fixes) and pushed it
out to main yesterday.
Cheers,
Tom
On Thu, Aug 13, 2020 at 10:57 PM 张二东 wrote:
> Hi:
>The function umr_pm4_decode_ring_is_halted call umr_read_ring_data
>
> to get ringdata, umr_read_ring_data will alloc
ault in arcturus_get_smu_metrics_data()
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
index 8b1025dc54fd..f6fe8e0ff977 10
out of arcturus_log_thermal_throttling_event() if it fails.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
b/drivers/gpu/drm/amd/powerplay/arcturus_ppt.c
i
| __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
| ^
drivers/gpu/drm/amd/amdgpu/df_v3_6.c:649:11: note: ‘lo_base_addr’ was declared
here
649 | uint32_t lo_base_addr, hi_base_addr, lo_val = 0, hi_val = 0;
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/df_v3_6.c | 2 +-
1 file
Despite having different IP offsets the computed address of the register(s)
are the same between gfx7..gfx10. This patch fixes the offset relative
to the GC block on gfx10.
(v2): SQ_DEBUG_STS_GLOBAL2 is 0x10 higher ...
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/include/asic_reg/gc
Despite having different IP offsets the computed address of the register(s)
are the same between gfx7..gfx10. This patch fixes the offset relative
to the GC block on gfx10.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h | 4 ++--
drivers/gpu/drm/amd
Forgot to subtract the SOC15 IP offsetand add the BASE_IDX values.
Signed-off-by: Tom St Denis
---
.../gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_offset.h | 6 --
.../gpu/drm/amd/include/asic_reg/gc/gc_10_3_0_offset.h | 6 --
drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_0_offset.h
Even though they are technically MMIO registers I put the bits with the sqind
block
for organizational purposes.
Requested for UMR debugging.
Signed-off-by: Tom St Denis
---
.../include/asic_reg/gc/gc_10_1_0_offset.h| 3 ++-
.../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 16
Requested for UMR support.
Signed-off-by: Tom St Denis
---
.../include/asic_reg/gc/gc_10_1_0_offset.h| 1 +
.../include/asic_reg/gc/gc_10_1_0_sh_mask.h | 20 +++
.../include/asic_reg/gc/gc_10_3_0_offset.h| 1 +
.../include/asic_reg/gc/gc_10_3_0_sh_mask.h | 19
Requested bits for UMR support
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/include/asic_reg/gc/gc_10_1_0_sh_mask.h
b/drivers/gpu/drm/amd/include/asic_reg/gc
On my raven1 system (rev c6) with VBIOS 113-RAVEN-114 GFXOFF is
not stable (resulting in large block tiling noise in some applications).
Disabling GFXOFF via the quirk list fixes the problems for me.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++
1 file changed
e at the same locations) this works out fine.
Tom
Alex
From:
amd-gfx on
behalf of Tom St Denis
Sent: Wednesday,
The PWR block was merged into the SMUIO block by revision 12 so we add
that to the smuio_12_0_0 headers.
(v2): Drop nonsensical smuio_10_0_0 header
Signed-off-by: Tom St Denis
---
.../gpu/drm/amd/include/asic_reg/smuio/smuio_12_0_0_offset.h | 3 +++
.../drm/amd/include/asic_reg/smuio
The PWR block was merged into the SMUIO block by revision 12 so we add
that to the smuio_12_0_0 headers and then create a new smio_10_0_0 that
raven1 can use in conjunction with the pwr_10_0 headers.
Signed-off-by: Tom St Denis
---
.../asic_reg/smuio/smuio_10_0_0_offset.h | 27
This register is needed by umr.
Signed-off-by: Tom St Denis
---
.../asic_reg/smuio/smuio_12_0_0_offset.h | 27 ++
.../asic_reg/smuio/smuio_12_0_0_sh_mask.h | 28 +++
2 files changed, 55 insertions(+)
create mode 100644
drivers/gpu/drm/amd/include
The register is part of the PWR block not the GC block. Move to
its own header.
Signed-off-by: Tom St Denis
---
.../amd/include/asic_reg/gc/gc_9_1_offset.h | 2 --
.../amd/include/asic_reg/gc/gc_9_1_sh_mask.h | 5
.../include/asic_reg/pwr/pwr_10_0_offset.h| 27
-03-11 11:16 a.m., Alex Deucher wrote:
On Tue, Mar 10, 2020 at 8:53 AM Tom St Denis wrote:
The offset into the array was specified in bytes but should
be in terms of 32-bit words. Also prevent large reads that
would also cause a buffer overread.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm
The offset into the array was specified in bytes but should
be in terms of 32-bit words. Also prevent large reads that
would also cause a buffer overread.
v2: Read from correct offset from internal storage buffer.
Signed-off-by: Tom St Denis
Acked-by: Christian König
---
drivers/gpu/drm/amd
On 2020-03-11 11:16 a.m., Alex Deucher wrote:
On Tue, Mar 10, 2020 at 8:53 AM Tom St Denis wrote:
The offset into the array was specified in bytes but should
be in terms of 32-bit words. Also prevent large reads that
would also cause a buffer overread.
Signed-off-by: Tom St Denis
Sorry about missing that. A fix was sent to the list a few mins ago.
It also highlighted a bug in umr's reading of trap registers. It's a
genuine two-fer!
Tom
On 2020-03-10 8:23 a.m., Dan Carpenter wrote:
On Tue, Nov 28, 2017 at 09:37:44AM -0500, Tom St Denis wrote:
On 28/11/17 09:29 AM
The offset into the array was specified in bytes but should
be in terms of 32-bit words. Also prevent large reads that
would also cause a buffer overread.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
On 2020-02-21 1:59 p.m., Alex Deucher wrote:
On Fri, Feb 21, 2020 at 1:45 PM Tom St Denis wrote:
Write a 32-bit value of zero to disable GFXOFF and write a 32-bit
value of non-zero to enable GFXOFF.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 56
Thanks, both pushed out to the master branch.
Cheers,
Tom
On 2020-02-24 5:59 a.m., Xiaojie Yuan wrote:
otherwise we'll out-of-bound when accessing op_37_dst_sel[8]
Signed-off-by: Xiaojie Yuan
---
src/lib/ring_decode.c| 2 +-
src/lib/umr_pm4_decode_opcodes.c | 2 +-
2 files
Write a 32-bit value of zero to disable GFXOFF and write a 32-bit
value of non-zero to enable GFXOFF.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 56 +
1 file changed, 56 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu
nis, Tom
<mailto:tom.stde...@amd.com>
>> 抄送: Alex Deucher
<mailto:alexdeuc...@gmail.com>; amd-gfx list
<mailto:amd-gfx@lists.freedesktop.org>
>> 主题: Re: [PATCH] drm/amd/amdgpu: disable GFXOFF around debugfs
access to MMIO
>>
>> On Wed, Feb 19, 202
On 2020-02-21 9:34 a.m., Huang Rui wrote:
On Wed, Feb 19, 2020 at 10:09:46AM -0500, Tom St Denis wrote:
I got some messages after a while:
[ 741.788564] Failed to send Message 8.
[ 746.671509] Failed to send Message 8.
[ 748.749673] Failed to send Message 2b.
[ 759.245414] Failed to send
resolution should be simple, just keep the
vm->update_funcs->prepare(...) line as it is in your branch.
When you get those errors then something went wrong in your rebase.
Christian.
Am 19.02.20 um 16:14 schrieb Tom St Denis:
Doesn't build even with conflict resolved:
[root@raven linux]# make
Doesn't build even with conflict resolved:
[root@raven linux]# make
CALL scripts/checksyscalls.sh
CALL scripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/amd/amdgpu/amdgpu_vm.o
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c: In
:04 AM Tom St Denis wrote:
Signed-off-by: Tom St Denis
Please add a patch description. With that fixed:
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers
Ignore that my brain wasn't engaged in the process. It's clear where
you wanted the prepare call.
Tom
On 2020-02-19 10:06 a.m., Tom St Denis wrote:
I get this conflict on top of drm-next
++<<<<<<< HEAD
+ r = vm->update_funcs->prepare(, resv, sync_mode);
I get this conflict on top of drm-next
++<<< HEAD
+ r = vm->update_funcs->prepare(, resv, sync_mode);
++===
+ if (flags & AMDGPU_PTE_VALID) {
+ struct amdgpu_bo *root = vm->root.base.bo;
+
+ if (!dma_fence_is_signaled(vm->last_direct))
+
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index 7379910790c9..66f763300c96 100644
--- a/drivers/gpu/drm/amd/amdgpu
This doesn't apply on top of 7fd3b632e17e55c5ffd008f9f025754e7daa1b66
which is the tip of drm-next
Tom
On 2020-02-19 9:20 a.m., Christian König wrote:
Add update fences to the root PD while mapping BOs.
Otherwise PDs freed during the mapping won't wait for
updates to finish and can cause
Hmm it doesn't apply on top of the tip of master. I'll just manually
apply it.
Tom
On 2020-02-19 6:56 a.m., Xiaojie Yuan wrote:
field names for INDIRECT_BUFFER_CONST/CIK of gfx9/gfx10 are the same.
fields like OFFLOAD_POLLING and VALID are defined in mec's
INDIRECT_BUFFER packet, so not
Yup, my bad. We also need to fix the streaming version (line 432 of
src/lib/umr_pm4_decode_opcodes.c). Would you like to incorporate this
into this patch? Otherwise I can do it separately.
Thanks,
Tom
On 2020-02-19 6:26 a.m., Xiaojie Yuan wrote:
field names for INDIRECT_BUFFER_CONST/CIK
Both fixes pushed out to master (on gitlab)
Thanks again!
Tom
On 2020-02-14 10:06 a.m., Yuan, Xiaojie wrote:
Thanks Tom. I'm just publishing this quick fix so that I can continue my
debugging with umr, and your solution sounds more reasonable ; )
BR,
Xiaojie
On Feb 14, 2020, at 10:55
Hi,
Thanks for the patch however since the *.i files are machine generate
I'd rather like to avoid patches like this (since they will need to be
continually applied).
The ideal solution is to either patch src/lib/read_vram.c or to patch
the kernel headers. The kernel headers are also
to figure it out by tomorrow now,
Christian.
Am 27.01.20 um 18:37 schrieb Tom St Denis:
The offending PDE address is: "3eff60"
Which looks like it was sign extended into the "reserved" section
between bits 40:58 (0x3fff) hence triggering the BUG() in the gmc_v8
driver.
Tom
The offending PDE address is: "3eff60"
Which looks like it was sign extended into the "reserved" section
between bits 40:58 (0x3fff) hence triggering the BUG() in the gmc_v8 driver.
Tom
On 2020-01-27 9:57 a.m., Tom St Denis wrote:
Reverting this patch avoids
Reverting this patch avoids the gmc_v8 errors (I previously sent kernel
logs, here's one for convenience):
[ 358.554335] [ cut here ]
[ 358.554338] kernel BUG at drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:725!
[ 358.554351] invalid opcode: [#1] SMP NOPTI
[
I've tested piglit, unigine-heaven, and video playback on my
navi10/raven1 system. All fine (as far as the kernel is concerned).
You can add my
Tested-by: Tom St Denis
Tom
On 2020-01-23 9:35 a.m., Christian König wrote:
That is fixed by patch #2 in this series.
Patch #4 is then re
-23 9:24 a.m., Christian König wrote:
Thanks, please give them a full round.
Took me a week to figure out that we accidentally pass in the
reservation object as NULL for cleared BOs.
Thanks,
Christian.
Am 23.01.20 um 15:22 schrieb Tom St Denis:
Just applied these now, trying them out
Just applied these now, trying them out will report back in ~20 mins.
On 2020-01-23 9:21 a.m., Christian König wrote:
If provided we only sync to the BOs reservation
object and no longer to the root PD.
v2: update comment, cleanup amdgpu_bo_sync_wait_resv
v3: use correct reservation object
I'll test it out in a minute.
Tom
On 2020-01-16 10:28 a.m., Christian König wrote:
We don't need to return an error in this case.
Signed-off-by: Christian König
Fixes: d6932a4d86e4 drm/amdgpu: make sure to never allocate PDs/PTs for
invalidations
---
Tested-by: Tom St Denis
On 2020-01-15 9:34 a.m., Christian König wrote:
This reverts commit 75a0d3f5e4a8dc70c22842ec1fde2866f27f48b9.
It's causing VM page faults, revert until further investigated.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 37
note: I have since fixed the #ifndef/#define lines for when I eventually
push it out
On Thu, Jan 9, 2020 at 10:40 AM Tom St Denis wrote:
> Signed-off-by: Tom St Denis
> ---
> .../include/asic_reg/umc/umc_6_1_2_sh_mask.h | 91 +++
> 1 file changed, 91 insertions(
Signed-off-by: Tom St Denis
---
.../include/asic_reg/umc/umc_6_1_2_sh_mask.h | 91 +++
1 file changed, 91 insertions(+)
create mode 100644 drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_1_2_sh_mask.h
diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_6_1_2_sh_mask.h
b
Tested-by: Tom St Denis
Cheers,
Tom
On Thu, Oct 3, 2019 at 1:30 PM Alex Deucher wrote:
> Check the number of supported vectors and fall back to MSI if
> we return or error or 0 MSI-X vectors.
>
> v2: only allocate one vector. We can't currently use more than
> one anyway.
ping?
On Fri, Jun 14, 2019 at 12:51 PM StDenis, Tom wrote:
> On 32-bit hosts mem->num_pages is 32-bits and can overflow
> when shifted. Add a cast to avoid this.
>
> Signed-off-by: Tom St Denis
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8 +---
> 1 fi
ping?
On Tue, Jun 4, 2019 at 1:15 PM StDenis, Tom wrote:
> This option is no longer needed. The default code paths
> are now the only option.
>
> v2: Add HPAGE support and a default for non contiguous maps
>
> Signed-off-by: Tom St Denis
> ---
> drivers/gpu
lists is inconsistent
>
>
> --
> *From:* amd-gfx on behalf of
> StDenis, Tom
> *Sent:* Thursday, May 30, 2019 10:56 AM
> *To:* amd-gfx@lists.freedesktop.org
> *Cc:* StDenis, Tom
> *Subject:* [PATCH] drm/amd/doc: add rough outline of tracepoint
> documentation
>
> Signed-o
Hi,
Alex can I get an RB on this :-)
Thanks,
Tom
On Mon, Mar 4, 2019 at 10:59 AM StDenis, Tom wrote:
> Signed-off-by: Tom St Denis
> ---
> drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h | 2 ++
> drivers/gpu/drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h | 5
g,
Tom
Thanks,
Christian.
Am 18.09.2018 um 16:20 schrieb Tom St Denis:
On 2018-09-18 10:13 a.m., Christian König wrote:
Mhm, there is no more failed IB-test in there isn't it?
oh sorry I thought you wanted to test HEAD~ ... Attached is a log from
the tip of drm-next
Tom
Chris
On 2018-09-18 10:13 a.m., Christian König wrote:
Mhm, there is no more failed IB-test in there isn't it?
oh sorry I thought you wanted to test HEAD~ ... Attached is a log from
the tip of drm-next
Tom
Christian.
Am 18.09.2018 um 16:09 schrieb Tom St Denis:
Disabling IOMMU in the BIOS
Disabling IOMMU in the BIOS resulted in a correct boot up...
Here's the log.
Tom
On 2018-09-18 9:58 a.m., Tom St Denis wrote:
Odd I couldn't even boot my system with the dGPU as primary after
rebuilding the kernel. It got hung up in the IOMMU driver (loads of
AMD-Vi IOMMU errors) which I
a.m., Christian König wrote:
Am 18.09.2018 um 15:32 schrieb Tom St Denis:
On 2018-09-18 9:30 a.m., Christian König wrote:
Great, not sure if that is a good or a bad news.
Anyway going to revert the change for now. Does anybody volunteer to
figure out why interrupts sometimes doesn't work
orkstation is a Raven1 (Ryzen
2400G) and other than the TTM bulk move issue has been perfectly stable
(through suspend/resumes too I might add).
Anything I could test with my devel raven?
Tom
Christian.
Am 18.09.2018 um 15:27 schrieb Tom St Denis:
This commit:
[root@raven linux]# git b
This commit:
[root@raven linux]# git bisect good
9b0df0937a852d299fbe42a5939c9a8a4cc83c55 is the first bad commit
commit 9b0df0937a852d299fbe42a5939c9a8a4cc83c55
Author: Christian König
Date: Tue Sep 18 10:38:09 2018 +0200
drm/amdgpu: remove fence fallback
DC doesn't seem to have a
On 2018-09-17 2:08 p.m., Christian König wrote:
Am 17.09.2018 um 20:07 schrieb Tom St Denis:
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
You was faster than me :)
Been a while since I got a patch on the kernel side... need to keep up
numbers :-)
Tom
---
drivers/gpu
I've sent a patch to the list that fixes the bug on my end.
Cheers,
Tom
On 2018-09-17 2:01 p.m., Tom St Denis wrote:
On 2018-09-17 1:55 p.m., Christian König wrote:
Am 17.09.2018 um 19:50 schrieb Tom St Denis:
On 2018-09-17 1:45 p.m., Christian König wrote:
Mhm, not the slightest idea
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 84d82d5382f9..c1387efc0c91 100644
--- a/drivers/gpu/drm
On 2018-09-17 1:55 p.m., Christian König wrote:
Am 17.09.2018 um 19:50 schrieb Tom St Denis:
On 2018-09-17 1:45 p.m., Christian König wrote:
Mhm, not the slightest idea.
That nearly looks like adev->stolen_vga_memory already contains
something.
Nope,
[ 51.564605] >
oduct
Name/TUF B350M-PLUS GAMING, BIOS 4011 04/19/2018
[ 51.565714] RIP: 0010:amdgpu_bo_create_kernel+0x59/0x1a0 [amdgpu]
That's me printing out the value of the value for stolen_vga_memory
before the call to allocate it.
Tom
Christian.
Am 17.09.2018 um 18:47 schrieb Tom St Denis:
On 2018-
On 2018-09-17 12:21 p.m., Tom St Denis wrote:
(attached). I'll try to bisect in a second. Is anyone aware of this?
Tom
Bisection led to:
a327772a5655ff4fb104c8aae6515faa461df466 is the first bad commit
commit a327772a5655ff4fb104c8aae6515faa461df466
Author: Christian König
Date: Fri Sep
1 - 100 of 778 matches
Mail list logo
