On 2022-11-25 02:59, Christian König wrote:
> Am 25.11.22 um 08:56 schrieb Luben Tuikov:
>> On 2022-11-25 02:45, Christian König wrote:
>>>
>>> Am 24.11.22 um 22:19 schrieb Luben Tuikov:
Fix minmax compilation error by using min_t()/max_t(), of the assignment
type.
Cc: James Zh
We re-arranged this code recently so "ret" is always zero at this point.
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
With this set applied, I am able to obtain a successful allmodconfig A
bw_calcs() presently blows the stack-frame limit by calling functions
inside a argument list which return quite a bit of data to be passed
onto sub-functions. Simply breaking out this hunk reduces the
stack-frame use by 500 Bytes, preventing the following compiler
warning:
drivers/gpu/drm/amd
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
architectures built with Clang (all released versions), whereby the stack
frame gets blown up to well over 5k. This would cause an immediate kernel
panic on most architectures. We'll revert this when the following bug
When enabled, KASAN enlarges function's stack-frames. Pushing quite a
few over the current threshold. This can mainly be seen on 32-bit
architectures where the present limit (when !GCC) is a lowly
1024-Bytes.
Signed-off-by: Lee Jones
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
Am 25.11.22 um 09:33 schrieb Luben Tuikov:
On 2022-11-25 02:59, Christian König wrote:
Am 25.11.22 um 08:56 schrieb Luben Tuikov:
On 2022-11-25 02:45, Christian König wrote:
Am 24.11.22 um 22:19 schrieb Luben Tuikov:
Fix minmax compilation error by using min_t()/max_t(), of the assignment
We already fallback to a dummy BO with no backing store when we
allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
Drop all those workarounds and generalize this for GTT as well. This
fixes ENOMEM issues with runaway applications which try to allocate/free
GTT in a loop and are ot
Instead of a single worker going over the list of delete BOs in regular
intervals use a per BO worker which blocks for the resv object and
locking of the BO.
This not only simplifies the handling massively, but also results in
much better response time when cleaning up buffers.
Signed-off-by: Chr
Those functions never worked correctly since it is still perfectly
possible that a buffer object is released and the background worker
restarted even after calling them.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_
Merge and cleanup the two headers into a single description of the
object API. Also move all the documentation to the implementation and
drop unecessary includes from the header.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +-
...
Not used anymore by other drivers or TTM itself.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c| 44 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 19 -
drivers/gpu/drm/vmwgfx/ttm_object.h | 11
include/drm/ttm/ttm_bo.h
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 11 ---
2 files changed, 13 insertions(+), 4 deletions(-)
diff --gi
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_cmd.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl
Make sure that we use the correct settings from the context.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f9d9fd2d865d..cd266a067773 100644
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
Since b339ec9c229aa ("kbuild: Only default to -Werror if COMPILE_TEST") WERROR
now defaults to COMPILE_TEST meaning that it's enabled for allmodconfig
builds. This leads to some interesting failures, each resolved in this set.
calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
architectures built with Clang (all released versions), whereby the stack
frame gets blown up to well over 5k. This would cause an immediate kernel
panic on most architectures. We'll revert this when the following bug
When enabled, KASAN enlarges function's stack-frames. Pushing quite a
few over the current threshold. This can mainly be seen on 32-bit
architectures where the present limit (when !GCC) is a lowly
1024-Bytes.
Signed-off-by: Lee Jones
---
lib/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
Am 25.11.22 um 12:14 schrieb Tvrtko Ursulin:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file ch
On Fri, 25 Nov 2022, Lee Jones wrote:
> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
> few over the current threshold. This can mainly be seen on 32-bit
> architectures where the present limit (when !GCC) is a lowly
> 1024-Bytes.
>
> Signed-off-by: Lee Jones
> ---
> l
On Fri, Nov 25, 2022, at 14:40, Lee Jones wrote:
> On Fri, 25 Nov 2022, Lee Jones wrote:
>
>> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
>> few over the current threshold. This can mainly be seen on 32-bit
>> architectures where the present limit (when !GCC) is a lowly
On Fri, Nov 25, 2022, at 13:07, Lee Jones wrote:
> calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
> architectures built with Clang (all released versions), whereby the stack
> frame gets blown up to well over 5k. This would cause an immediate kernel
> panic on most
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> When enabled, KASAN enlarges function's stack-frames. Pushing quite a
> few over the current threshold. This can mainly be seen on 32-bit
> architectures where the present limit (when !GCC) is a lowly
> 1024-Bytes.
>
> Signed-off-by: Lee Jones
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> bw_calcs() presently blows the stack-frame limit by calling functions
> inside a argument list which return quite a bit of data to be passed
> onto sub-functions. Simply breaking out this hunk reduces the
> stack-frame use by 500 Bytes, preventing
On Fri, Nov 25, 2022, at 10:25, Lee Jones wrote:
> calculate_bandwidth() is presently broken on all !(X86_64 || SPARC64 || ARM64)
> architectures built with Clang (all released versions), whereby the stack
> frame gets blown up to well over 5k. This would cause an immediate kernel
> panic on most
On 2022-11-25 02:39, Dan Carpenter wrote:
We re-arranged this code recently so "ret" is always zero at this point.
Signed-off-by: Dan Carpenter
Reviewed-by: Felix Kuehling
I'm applying your patch to amd-staging-drm-next. Thank you!
Felix
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c |
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 9e46a79967326efb03c481ddfd58902475bd920d Add linux-next specific
files for 20221125
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com
https
On 2022-11-24 15:27, Kim, Jonathan wrote:
[AMD Official Use Only - General]
-Original Message-
From: Kuehling, Felix
Sent: November 24, 2022 11:24 AM
To: Kim, Jonathan ; amd-
g...@lists.freedesktop.org
Subject: Re: [PATCH 17/29] drm/amdkfd: Add debug trap enabled flag to
TMA
Am 202
On Thu, Nov 24, 2022 at 12:29 AM Guchun Chen wrote:
>
> Runtime PM can happen pretty frequently, as these printings
> may be annoyed, switch to dev_dbg.
>
> Suggested-by: Lijo Lazar
> Signed-off-by: Guchun Chen
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
[AMD Official Use Only - General]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U
Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U
Sapphire Pulse RX5700XT
Reference AMD RX6800
These syste
This patchset adds a udev event for DRM device's resets.
Userspace apps can trigger GPU resets by misuse of graphical APIs or driver
bugs. Either way, the GPU reset might lead the system to a broken state[1], that
might be recovered if user has access to a tty or a remote shell. Arguably, this
rec
From: Shashank Sharma
Add a sysfs event to notify userspace about GPU resets providing:
- PID that triggered the GPU reset, if any. Resets can happen from
kernel threads as well, in that case no PID is provided
- Information about the reset (e.g. was VRAM lost?)
Co-developed-by: André Almeida
Add a work function to send a GPU reset uevent and scheduled it during
a GPU reset.
Co-developed-by: Shashank Sharma
Signed-off-by: Shashank Sharma
Signed-off-by: André Almeida
---
V3:
- Merge two last commits
V2: Addressed review comments from Christian
- Changed the name of the work to
Hi Dave, Daniel,
More stuff for 6.2. Mostly bug fixes at this point.
The following changes since commit 3d335a523b938a445a674be24d1dd5c7a4c86fb6:
Merge tag 'drm-intel-next-2022-11-18' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-11-23 09:15:44
+1000)
are available in
On Fri, Nov 25, 2022 at 5:21 AM Christian König
wrote:
>
> We already fallback to a dummy BO with no backing store when we
> allocate GDS,GWS and OA resources and to GTT when we allocate VRAM.
>
> Drop all those workarounds and generalize this for GTT as well. This
> fixes ENOMEM issues with runaw
Applied the series. Thanks!
Alex
On Tue, Nov 22, 2022 at 6:13 AM Xiongfeng Wang
wrote:
>
> As comment of pci_get_class() says, it returns a pci_device with its
> refcount increased and decreased the refcount for the input parameter
> @from if it is not NULL.
>
> If we break the loop in amdgpu_a
On 2022-11-25 04:57, Christian König wrote:
>
>
> Am 25.11.22 um 09:33 schrieb Luben Tuikov:
>> On 2022-11-25 02:59, Christian König wrote:
>>> Am 25.11.22 um 08:56 schrieb Luben Tuikov:
On 2022-11-25 02:45, Christian König wrote:
> Am 24.11.22 um 22:19 schrieb Luben Tuikov:
>> Fix m
Currently, there are issues with enabling PSR-SU + DSC. This stems from
the fact that DSC imposes a slice height on transmitted video data and
we are not conforming to that slice height in PSR-SU regions. So, pass
slice_height into su_y_granularity to feed the DSC slice height into
PSR-SU code.
Si
On 2022-11-25 14:42, Luben Tuikov wrote:
On 2022-11-25 04:57, Christian König wrote:
Am 25.11.22 um 09:33 schrieb Luben Tuikov:
On 2022-11-25 02:59, Christian König wrote:
Am 25.11.22 um 08:56 schrieb Luben Tuikov:
On 2022-11-25 02:45, Christian König wrote:
Am 24.11.22 um 22:19 schrieb L
On 2022-11-25 16:03, James Zhu wrote:
>
> On 2022-11-25 14:42, Luben Tuikov wrote:
>> On 2022-11-25 04:57, Christian König wrote:
>>>
>>> Am 25.11.22 um 09:33 schrieb Luben Tuikov:
On 2022-11-25 02:59, Christian König wrote:
> Am 25.11.22 um 08:56 schrieb Luben Tuikov:
>> On 2022-11-2
Fix minmax compilation error by using the correct constant and correct integer
suffix.
Cc: James Zhu
Cc: Felix Kuehling
Fixes: 58170a7a002ad6 ("drm/amdgpu: fix stall on CPU when allocate large system
memory")
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c | 6 +++---
43 matches
Mail list logo
