Ok that sounds like a rather simple bug. I will try to take a look.
Thanks,
Christian.
Am 17.05.22 um 02:12 schrieb Marek Olšák:
Dmesg doesn't contain anything. There is no backtrace because it's not
a crash. The VA map ioctl just fails with the new flag. It looks like
the flag is considered i
From: Haohui Mai
Remove the accidental shifts on the values of RPTR_BLOCK_SIZE in gfx_v8-v11.
The bug essentially always programs the corresponding fields to zero
instead of the correct value.
Signed-off-by: Haohui Mai
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
drivers/gpu/drm/amd/amdg
With the latest vbios, the memory temp reading is working.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Change-Id: I3b4679f03e5ff7cf8e0b68c095d210e608149fcb
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/p
Enable OOB Monitor and SOC CG which are ready since 78.38.0.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Acked-by: Alex Deucher
Change-Id: I0d7334106917ac83fff2b673ec7e9eb096089afe
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +++
1 file changed, 3 insertions(+)
diff -
To align with 78.37.0 and later PMFWs.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Change-Id: I17c3a6b466c921cb5ffe5025a94023fae478c80e
---
.../inc/pmfw_if/smu13_driver_if_v13_0_0.h | 22 +--
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +-
2 files changed, 11
Since PMFW will handle this properly. Driver involvement is
unnecessary.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Change-Id: I19be26eed090d57040553f5cdff9534072f08106
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd
To better match with the pptable_id settings from VBIOS.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Acked-by: Alex Deucher
Change-Id: I3379443067a5df3a2fb04ff1bc48e8c8f28e1c66
---
.../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c| 47 ++-
1 file changed, 35 insertions(+),
Enable MP0CLK DPM and FW Dstate since they are already supported
by latest 78.36.0 PMFW.
Signed-off-by: Evan Quan
Reviewed-by: Hawking Zhang
Change-Id: I75b6129dab509a51ccaf92bbc0b094eae41ea20f
---
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +++
1 file changed, 3 insertions(+)
di
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, May 17, 2022 2:17 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu/discovery: validate VCN and SDMA instances
Validate the VCN and
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 3f7bdc402fb06f897ff1f492a2d42e1f7c2efedb Add linux-next specific
files for 20220516
Error/Warning reports:
https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com
https
Dmesg doesn't contain anything. There is no backtrace because it's not a
crash. The VA map ioctl just fails with the new flag. It looks like the
flag is considered invalid.
Marek
On Mon., May 16, 2022, 12:13 Christian König, <
ckoenig.leichtzumer...@gmail.com> wrote:
> I don't have access to any
With DEVICE_COHERENT, we'll soon have vm_normal_pages() return
device-managed anonymous pages that are not LRU pages. Although they
behave like normal pages for purposes of mapping in CPU page, and for
COW. They do not support LRU lists, NUMA migration or THP.
We also introduced a FOLL_LRU flag th
The objective is to test device migration mechanism in pages marked
as COW, for private and coherent device type. In case of writing to
COW private page(s), a page fault will migrate pages back to system
memory first. Then, these pages will be duplicated. In case of COW
device coherent type, pages
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
The intention is to test hmm device coherent type under different get
user pages paths. Also, test gup with FOLL_LONGTERM flag set in
device coherent pages. These pages should get migrated back to system
memory.
Signed-off-by: Alex Sierra
Reviewed-by: Alistair Popple
---
tools/testing/selftests
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Also
Test cases such as migrate_fault and migrate_multiple, were modified to
explicit migrate from device to sys memory without the need of page
faults, when using device coherent type.
Snapshot test case updated to read memory device type first and based
on that, get the proper returned results migrat
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
From: Alistair Popple
migrate_vma_setup() checks that a valid vma is passed so that the page
tables can be walked to find the pfns associated with a given address
range. However in some cases the pfns are already known, such as when
migrating device coherent pages during pin_user_pages() meaning
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
lib/test_hmm.c | 23 +--
lib/test_
From: Alistair Popple
Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.
However this is no reason to fail pinning of these pages.
Device memory that is cache coherent from device and CPU point of view.
This is used on platforms that have an advanced system bus (like CAPI
or CXL). Any page of a process can be migrated to such memory. However,
no one should be allowed to pin such memory so that it can always be
evicted.
Signed
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
Acked-by: Felix Kuehling
Reviewed-by: Alistair Poppple
Signed-off-by: Christoph Hellwig
---
include/linux/m
This is our MEMORY_DEVICE_COHERENT patch series rebased and updated
for current 5.18-rc7.
Changes since the last version:
- Fixed problems with migration during long-term pinning in
get_user_pages
- Open coded vm_normal_lru_pages as suggested in previous code review
- Update hmm_gup_test with more
clone DRM.debug interface to DRM.tracebits: ie map bits to
drm-debug-categories, except this interface enables messages to
tracefs, not to syslog.
This reuses dyndbg's register-classes API to add the new sysfs-knob:
drm_drv.h:
[A] 2nd use of DYNAMIC_DEBUG_CLASSES(drm_trace_classes), which
declar
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
Add a struct _ddebug ptr to drm_dbg() and drm_dev_dbg() protos, and
upgrade their callers - the interposed macros added recently, to use
_dynamic_func_call_no_desc(); ie drop the '_no_desc', since the
factory macro's callees (these 2 functions) are now expecting the arg.
This makes those functions
add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition
CC: vincent.whitchu...@axis.com
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 0a
adds: ddebug_trace()
uses trace_console() temporarily to issue printk:console event
uses internal-ish __ftrace_trace_stack code:
4-context buffer stack, barriers per Steve Rostedt
call it from new funcs:
ddebug_printk() - print to both syslog/tracefs
ddebug_dev_printk() - dev-print to
Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit:
_DPRINTK_FLAGS_PRINT (and define former as latter), in preparation to
add another bit next: _DPRINTK_FLAGS_TRACE
And change JUMP_LABEL code block to use the more general
_DPRINTK_FLAGS_ENABLED symbol. Also add a 'K' to get new symbol
ddebug_trace() currently issues a single printk:console event.
Replace that, adding include/trace/events/dyndbg.h, which defines 2
new events:
- dyndbg:prdbg - from trace_prdbg() - if !dev
- dyndbg:devdbg - from trace_devdbg() - if !!dev
This links the legacy pr_debug API to tracefs, via dyndbg
In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics, w
enum drm_debug_category has 10 categories, but is initialized with
bitmasks which require 10 bits of underlying storage. By using
natural enumeration, and moving the BIT(cat) into drm_debug_enabled(),
the enum fits in 4 bits, allowing the category to be represented
directly in pr_debug callsites,
Invoke DYNAMIC_DEBUG_CLASSES from drm_drv.h. This declares a
maybe-unused struct ddebug_known_classes_map var, initialized with:
. var: passed to dynamic_debug_register_classes()
. class-names: "DRM_UT_CORE", "DRM_UT_DRIVER", "DRM_UT_KMS", etc.
These names map to .class_id's by their index, ie:
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg()
in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
Next, those functions are adapted to accept a descriptor arg, and we
drop the _no_desc suffix, then the (~4000) drm.debug callsites will be
controllable by their
POC: adapt drm_print to use/test the bitmap callback support.
with dynamic_debug.verbose=1:
bash-5.1# echo 1 > /sys/module/drm/parameters/debug
[ 33.697039] dyndbg: set_dyndbg_classes: new 0x1 current 0x0
[ 33.697571] dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
[ 33.698072] dyndbg: no mat
Demonstrate dyndbg's "class FOO" and bitmap-to-classes support. This
support is meant to plug into drm.debug system, and largely replace
the use of drm_debug_enabled(category) with JUMP_LABELs.
Recap:
#> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control
This is made "safe" because dyndbg
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already. But test_dynamic_debug needs it in order to demonstrate all
the moving parts.
Note the __ prefix; its not intended for general use, and doesn't
include any bu
Upgrade single classes-map to list of them:
This allows multiple DYNAMIC_DEBUG_CLASSES(class-map)s per module,
using _base to segment the 0..30 classid space.
alter struct ddebug table:
replace .classes (a &map) with maps (list-head)
dynamic_debug_register_classes(map) - adds new map to maps li
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are not used 2x in a query; a thing
cannot be named both foo and bar (not even wildcards, no OR is
contemplated).
Amend the treatment of module; while still enforcing the 2x rule on
it, set the d
Extend the sysfs-node bitmap support to accept class-names
registered by the module, allowing:
#> echo DRM_UT_CORE,-DRM_UT_ATOMIC,+DRM_UT_KMS \
> /sys/module/drm/parameters/debug
Do this in param_set_dyndbg_class_strings(), which is called from
param_set_dyndbg_classes() when the inpu
Add kernel_param_ops and callbacks to implement a bitmap in a
sysfs-node. IE, add these:
- int param_set_dyndbg_classes()
- int param_get_dyndbg_classes()
- struct kernel_param_ops param_ops_dyndbg_classes
Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
non-static and ex
Add module-to-class validation, in
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", ddebug_validate_classname (called from
ddebug_change) requires that FOO is known to module X, otherwize X is
skipped entirely.
The choice of FOO is highly selective, giving
The added paragraph is slightly process oriented, rather than in
language of guarantees; I thought the implications were clear enough.
It does perhaps undersell the selectivity gained with string
class_names; only drm/* would sanely register DRM_UT_CORE etc, so
doing multiple "module {drm*,amdgpu,
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
We only need 4 bits for drm, and with that reserved, we have 2 to
spare on 32 bit builds; lets take one extra (5 bits total), and keep a
spare bit. 32 classes-p
Add dynamic_debug_register_classes() to API, allowing user modules
(builtin and loadable) to register class_names for the .class_id's
they are using. Knowing classes is 1st step to validating with them.
Add dynamic_debug_unregister_classes() also.
Add struct ddebug_known_classes_map: maps known c
For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb()
stub-fn is too permissive:
bash-5.1# modprobe drm JUNKdyndbg
bash-5.1# modprobe drm dyndbgJUNK
[ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds
[ 42.937484] ACPI: bus type drm_connector registered
This c
This exported fn is unused, and is effectively obsoleted by a
forthcoming commit, so remove it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But following patches
implement the drm.debug interface, and adapt drm to just use it, so
print "old -> new" flag values in the info("change") message.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a56c1286ffa4..ca2a28f1d51c 100644
In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/
Vincent's patch commented on, and worked around, a bug toggling
static_branch's, when a 2nd PRINTK-ish flag was added. The bug
results in a premature static_branch_disable when the 1st of 2 flags
was disabled.
The cited commit comp
DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
messages. By rough count, they are used 5140 times in the kernel.
These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(),
which checks bits in global __drm_debug. Some of these are page-flips
and vblanks, and get c
This fixes a kernel oops when MES is not enabled.
Reported-by: Kenny Ho
Suggested-by: Jack Xiao
Reviewed-by: Alex Deucher
Signed-off-by: Luben Tuikov
Fixes: d69e773ca75b8f ("drm/amdgpu: add mes unmap legacy queue routine")
Fixes: 36d7a7094750fc ("drm/amdgpu: add init support for GFX11 (v2)")
-
Am 2022-05-16 um 10:43 schrieb Jonathan Kim:
CPU hive assignment currently assumes when a GPU hive is connected_to_cpu,
there is only one hive in the system.
Only assign CPUs to the hive if they are explicitly directly connected to
the GPU hive to get rid of the need for this assumption.
It's m
Am 16.05.22 um 20:15 schrieb Alex Deucher:
On Mon, May 16, 2022 at 2:10 PM Christian König
wrote:
Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand:
Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote:
smatch found this problem on amd-staging-
It is to simplify trap handler support for new asics in
the future.
Signed-off-by: Eric Huang
---
.../gpu/drm/amd/amdkfd/cwsr_trap_handler.h| 2527 +
.../amd/amdkfd/cwsr_trap_handler_gfx10.asm| 325 ++-
.../drm/amd/amdkfd/cwsr_trap_handler_gfx9.asm | 244 +-
3 files cha
From: Jay Cornwall
Based on gfx10 with following changes:
- GPR_ALLOC.VGPR_SIZE field moved (and size corrected in gfx10)
- s_sendmsg_rtn_b64 replaces some s_sendmsg/s_getreg
- Buffer instructions no longer have direct-to-LDS modifier
Signed-off-by: Jay Cornwall
Reviewed-by: Laurent Morichetti
On Sun, 15 May 2022 21:00:21 +0800 kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 1e1b28b936aed946122b4e0991e7144fdbbfd77e Add linux-next
> specific files for 20220513
>
> Error/Warning reports:
>
> https://lo
Applied. Thanks!
Alex
On Mon, May 16, 2022 at 8:01 AM wrote:
>
> From: Haohui Mai
>
> Clean up redundant, copy-paste code blocks during the intialization of
> the doorbells in mqd_init().
>
> Signed-off-by: Haohui Mai
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 -
> d
Looks good to me!
Den mån 16 maj 2022 kl 20:15 skrev Alex Deucher :
> On Mon, May 16, 2022 at 2:10 PM Christian König
> wrote:
> >
> > Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand:
> >
> > Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
> >>
> >> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstran
Validate the VCN and SDMA instances against the driver
structure sizes to make sure we don't get into a
situation where the firmware reports more instances than
the driver supports.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 17 ++---
1 file chang
On Mon, May 16, 2022 at 2:10 PM Christian König
wrote:
>
> Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand:
>
> Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
>>
>> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote:
>> >
>> > smatch found this problem on amd-staging-drm-next:
>> >
>> > drive
Am 16.05.22 um 19:49 schrieb Ernst Sjöstrand:
Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand
wrote:
>
> smatch found this problem on amd-staging-drm-next:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
amdgp
Den mån 16 maj 2022 kl 17:13 skrev Alex Deucher :
> On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote:
> >
> > smatch found this problem on amd-staging-drm-next:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
> amdgpu_discovery_get_vcn_info() error: buffer overflow
> 'adev->vcn.v
On Mon, 16 May 2022 at 18:23, Leo Li wrote:
>
>
>
> On 2022-05-12 13:39, Daniel Vetter wrote:
> > On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David)
> > wrote:
> >>
> >> [AMD Official Use Only - General]
> >>
> >> Hi Daniel
> >>
> >> Thanks for your comments and explanations. I replied in-line
On 2022-05-12 13:39, Daniel Vetter wrote:
On Thu, 12 May 2022 at 19:22, Zhang, Dingchen (David)
wrote:
[AMD Official Use Only - General]
Hi Daniel
Thanks for your comments and explanations. I replied in-line and look forward
to more discussion.
regards
David
From: Daniel Vetter
Sent:
I don't have access to any gfx10 hardware.
Can you give me a dmesg and/or backtrace, etc..?
I can't push this unless it's working properly.
Christian.
Am 16.05.22 um 14:56 schrieb Marek Olšák:
Reproduction steps:
- use mesa/main on gfx10.3 (not sure what other GPUs do)
- run: radeonsi_mall_no
On 2022-05-16 11:08, Christian König wrote:
Am 16.05.22 um 16:12 schrieb Andrey Grodzovsky:
Ping
Ah, yes sorry.
Andrey
On 2022-05-13 11:41, Andrey Grodzovsky wrote:
Yes, exactly that's the idea.
Basically the reset domain knowns which amdgpu devices it needs to
reset together.
If yo
On Sun, May 15, 2022 at 11:46 AM Ernst Sjöstrand wrote:
>
> smatch found this problem on amd-staging-drm-next:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1443
> amdgpu_discovery_get_vcn_info() error: buffer overflow
> 'adev->vcn.vcn_codec_disable_mask' 2 <= 3
>
> This is caused by:
> #def
Am 16.05.22 um 16:12 schrieb Andrey Grodzovsky:
Ping
Ah, yes sorry.
Andrey
On 2022-05-13 11:41, Andrey Grodzovsky wrote:
Yes, exactly that's the idea.
Basically the reset domain knowns which amdgpu devices it needs to
reset together.
If you then represent that so that you always have
On Mon, May 16, 2022 at 8:40 AM Mike Lothian wrote:
>
> Hi
>
> The merge window for 5.19 will probably be opening next week, has
> there been any progress with this bug?
It took a while to find a combination of GPUs that would repro the
issue, but now that we can, it is still being investigated.
CPU hive assignment currently assumes when a GPU hive is connected_to_cpu,
there is only one hive in the system.
Only assign CPUs to the hive if they are explicitly directly connected to
the GPU hive to get rid of the need for this assumption.
It's more efficient to do this when querying IO links
Ping
Andrey
On 2022-05-13 11:41, Andrey Grodzovsky wrote:
Yes, exactly that's the idea.
Basically the reset domain knowns which amdgpu devices it needs to
reset together.
If you then represent that so that you always have a hive even when
you only have one device in it, or if you put an ar
[Public]
Hi all,
This week this patchset was tested on the following systems:
Sapphire Pulse RX5700XT
Reference AMD RX6800
Engineering board with Ryzen 9 5900H
These systems were tested on the following display types:
eDP, (1080p 60hz [5900H])
VGA and DVI (1680x1050 60HZ [DP to VGA/DVI, US
On Mon, Apr 25, 2022 at 01:22:04PM -0400, Alex Deucher wrote:
> + dri-devel
>
> On Mon, Apr 25, 2022 at 3:33 AM Krylov Michael wrote:
> >
> > Hello!
> >
> > After updating my Linux kernel from version 4.19 (Debian 10 version) to
> > 5.10 (packaged with Debian 11), I've noticed that the image
> >
Reproduction steps:
- use mesa/main on gfx10.3 (not sure what other GPUs do)
- run: radeonsi_mall_noalloc=true glxgears
Marek
On Mon, May 16, 2022 at 7:53 AM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Crap, do you have a link to the failure?
>
> Am 16.05.22 um 13:10 schrieb Mar
Alex Sierra writes:
> The intention is to test hmm device coherent type under different get
> user pages paths. Also, test gup with FOLL_LONGTERM flag set in
> device coherent pages. These pages should get migrated back to system
> memory.
>
> Signed-off-by: Alex Sierra
> ---
> tools/testing/
Hi
The merge window for 5.19 will probably be opening next week, has
there been any progress with this bug?
Thanks
Mike
On Mon, 2 May 2022 at 17:31, Mike Lothian wrote:
>
> On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam
> wrote:
> >
> >
> >
> > On 5/2/2022 8:41 PM, Mike Lothian wrote:
From: Haohui Mai
Clean up redundant, copy-paste code blocks during the intialization of
the doorbells in mqd_init().
Signed-off-by: Haohui Mai
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 17 -
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 17 -
2 files changed, 34 d
Crap, do you have a link to the failure?
Am 16.05.22 um 13:10 schrieb Marek Olšák:
I forgot to say: The NOALLOC flag causes an allocation failure, so
there is a kernel bug somewhere.
Marek
On Mon, May 16, 2022 at 7:06 AM Marek Olšák wrote:
FYI, I think it's time to merge this because th
I forgot to say: The NOALLOC flag causes an allocation failure, so there is
a kernel bug somewhere.
Marek
On Mon, May 16, 2022 at 7:06 AM Marek Olšák wrote:
> FYI, I think it's time to merge this because the Mesa commits are going to
> be merged in ~30 minutes if Gitlab CI is green, and that in
FYI, I think it's time to merge this because the Mesa commits are going to
be merged in ~30 minutes if Gitlab CI is green, and that includes updated
amdgpu_drm.h.
Marek
On Wed, May 11, 2022 at 2:55 PM Marek Olšák wrote:
> Ok sounds good.
>
> Marek
>
> On Wed., May 11, 2022, 03:43 Christian Köni
On Tue, 12 Apr 2022, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Intel-gfx On Behalf Of
>> Bhanuprakash Modem
>> Sent: Monday, April 11, 2022 3:21 PM
>> To: intel-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; amd-
>> g...@lists.freedesktop.org; jani.nik...@linux.i
On Mon, 02 May 2022, Harry Wentland wrote:
> Both the kernel and IGT series look good to me.
>
> I recommend you merge the entire kernel set as one into drm-next. We
> can pull it into amd-staging-drm-next so as not to break our CI once
> the IGT patches land.
Can we read that as an ack to merge
The > ARRAY_SIZE() should be >= ARRAY_SIZE() to prevent an out of bounds
access.
Fixes: e27c41d5b068 ("drm/amd/display: Support for DMUB HPD interrupt handling")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
86 matches
Mail list logo