tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: bc63de6e6ba0b16652c5fb4b9c9916b9e7ca1f23 Add linux-next specific
files for 20231208
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202312081716.luuhsns4-...@intel.com
https
When application tries to allocate all system memory and cause memory
to swap out. Needs more time for hmm_range_fault to validate the
remaining page for allocation. To be safe, increase timeout value to
1 second for 64MB range.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.
Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_hmm.c
b/drivers/gpu/drm/amd/amdgpu/a
Add begin/end_use ring callbacks to disallow GFXOFF when
SDMA work is submitted and allow it again afterward.
This should avoid corner cases where GFXOFF is erroneously
entered when SDMA is still active. For now just allow/disallow
GFXOFF in the begin and end helpers until we root cause the
issue
On Fri, Dec 8, 2023 at 5:19 PM Alex Deucher wrote:
>
> Add helper functions to disallow GFXOFF while SDMA has work.
> This should avoid corner cases where GFXOFF is erroneously
> entered when SDMA is still active. For now just allow/disallow
> GFXOFF in the begin and end helpers until we root cau
[Public]
> -Original Message-
> From: Deucher, Alexander
> Sent: Friday, December 8, 2023 5:19 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 2/3] drm/amdgpu/sdma5.0: add begin/end_use ring
> callbacks
>
> Add begin/end_use ring callbacks to disallow GF
On 12/8/2023 16:19, Alex Deucher wrote:
Add helper functions to disallow GFXOFF while SDMA has work.
This should avoid corner cases where GFXOFF is erroneously
entered when SDMA is still active. For now just allow/disallow
GFXOFF in the begin and end helpers until we root cause the
issue. This
Add begin/end_use ring callbacks to disallow GFXOFF when
SDMA work is submitted and allow it again afterward.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_2.c
b/drivers/gpu/drm/amd
Add begin/end_use ring callbacks to disallow GFXOFF when
SDMA work is submitted and allow it again afterward.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v5_0.c
b/drivers/gpu/drm/amd
Add helper functions to disallow GFXOFF while SDMA has work.
This should avoid corner cases where GFXOFF is erroneously
entered when SDMA is still active. For now just allow/disallow
GFXOFF in the begin and end helpers until we root cause the
issue. This should not impact power as SDMA usage is p
[Public]
> -Original Message-
> From: Chander, Vignesh
> Sent: Thursday, December 7, 2023 7:42 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Lazar, Lijo ; Luo, Zhigang
> ; Kim, Jonathan ;
> Chander, Vignesh
> Subject: [PATCH] drm/amdgpu: xgmi_fill_topology_info
>
> 1. Use the mirrored top
On Fri, Dec 8, 2023 at 7:55 AM Christian König
wrote:
>
> When freeing PD/PT with shadows it can happen that the shadow
> destruction races with detaching the PD/PT from the VM causing a NULL
> pointer dereference in the invalidation code.
>
> Fix this by detaching the the PD/PT from the VM first
Hi Dave, Sima,
More updates for 6.8.
The following changes since commit 5edfd7d94b0310b74136b666551f1d23711ed445:
Merge tag 'amd-drm-next-6.8-2023-12-01' of
https://gitlab.freedesktop.org/agd5f/linux into drm-next (2023-12-05 12:11:41
+1000)
are available in the Git repository at:
https:
On Fri, Dec 8, 2023 at 5:07 AM Christian König wrote:
>
> Am 07.12.23 um 16:11 schrieb Arunpravin Paneer Selvam:
> > Add clear page support in vram memory region.
>
> The first patch looks good, but this here needs quite some work.
>
> >
> > Signed-off-by: Arunpravin Paneer Selvam
> > ---
> > d
On Fri, Dec 8, 2023 at 8:24 AM Christian König
wrote:
>
> The second patch never made it into my inbox, but the first one is
> Reviewed-by: Christian König .
Thanks. Patch 2:
https://patchwork.freedesktop.org/patch/569132/
Alex
>
> Christian.
>
> Am 07.12.23 um 18:39 schrieb Alex Deucher:
> >
Le 08/12/2023 à 03:44, yang.gua...@zte.com.cn a écrit :
From: Yang Guang
Convert kzalloc/memcpy operations to memdup makes for
cleaner code and avoids memcpy() failures
Hi,
usually, function's names are written with () in commit description.
(i.e. kzalloc()/memcpy()).
memdup should be kme
On Fri, Dec 8, 2023 at 12:27 PM Joshua Ashton wrote:
>
> FWIW, we are shipping this right now in SteamOS Preview channel
> (probably going to Stable soon) and it seems to be working as expected
> and fixing issues there in instances we need to composite, compositor
> work we are forced to do would
[AMD Official Use Only - General]
Reviewed-by: Zhigang Luo
-Original Message-
From: Chander, Vignesh
Sent: Thursday, December 7, 2023 7:42 PM
To: amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Luo, Zhigang ; Kim,
Jonathan ; Chander, Vignesh
Subject: [PATCH] drm/amdgpu: xgmi_fill_topo
FWIW, we are shipping this right now in SteamOS Preview channel
(probably going to Stable soon) and it seems to be working as expected
and fixing issues there in instances we need to composite, compositor
work we are forced to do would take longer than the compositor redzone
to vblank.
Previo
On Fri, Dec 8, 2023 at 9:57 AM Christian König
wrote:
> Am 08.12.23 um 12:43 schrieb Friedrich Vock:
> > On 08.12.23 10:51, Christian König wrote:
> >> Well longer story short Alex and I have been digging up the
> >> documentation for this and as far as we can tell this isn't correct.
> > Huh. I
[AMD Official Use Only - General]
Christian, firmware has nothing to do with it and doesn't control it. That was
a wrong group of people to ping. It's only implemented in the SPI and tested by
the SPI team and PAL team.
Marek
From: Koenig, Christian
Sent: Decem
Am 08.12.23 um 12:43 schrieb Friedrich Vock:
On 08.12.23 10:51, Christian König wrote:
Well longer story short Alex and I have been digging up the
documentation for this and as far as we can tell this isn't correct.
Huh. I initially talked to Marek about this, adding him in Cc.
Yeah, from the
It's correct according to our documentation.
Reviewed-by: Marek Olšák
Marek
On Fri, Dec 8, 2023 at 5:47 AM Christian König
wrote:
> Well longer story short Alex and I have been digging up the
> documentation for this and as far as we can tell this isn't correct.
>
> You need to do quite a bit
'wb_info' needs to be freed on error paths or it would leak the memory.
Smatch pointed this out.
Fixes: c81e13b929df ("drm/amd/display: Hande writeback request from userspace")
Signed-off-by: Harshit Mogalapalli
---
This is based on static analysis and only compile tested
---
drivers/gpu/drm/am
The second patch never made it into my inbox, but the first one is
Reviewed-by: Christian König .
Christian.
Am 07.12.23 um 18:39 schrieb Alex Deucher:
Ping on this series?
Alex
On Mon, Nov 27, 2023 at 5:52 PM Alex Deucher wrote:
Should be -EOPNOTSUPP.
Fixes: 5104fdf50d32 ("drm/amdgpu: Fi
This can only happen when there is a reference counting bug.
v2: fix typo
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
When freeing PD/PT with shadows it can happen that the shadow
destruction races with detaching the PD/PT from the VM causing a NULL
pointer dereference in the invalidation code.
Fix this by detaching the the PD/PT from the VM first and then
freeinguthe shadow instead.
Signed-off-by: Christian Kön
On 08.12.23 10:51, Christian König wrote:
Well longer story short Alex and I have been digging up the
documentation for this and as far as we can tell this isn't correct.
Huh. I initially talked to Marek about this, adding him in Cc.
You need to do quite a bit more before you can turn on this
Am 07.12.23 um 20:14 schrieb Felix Kuehling:
On 2023-12-05 17:20, Felix Kuehling wrote:
Properly mark kfd_process->ef as __rcu and consistently access it with
rcu_dereference_protected.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202312052245.yfpbsgnh-...@int
Am 07.12.23 um 16:11 schrieb Arunpravin Paneer Selvam:
Add clear page support in vram memory region.
The first patch looks good, but this here needs quite some work.
Signed-off-by: Arunpravin Paneer Selvam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 13 +++--
.../gpu/drm/amd/amdg
Well longer story short Alex and I have been digging up the
documentation for this and as far as we can tell this isn't correct.
You need to do quite a bit more before you can turn on this feature.
What userspace side do you refer to?
Regards,
Christian.
Am 08.12.23 um 09:19 schrieb Friedric
Several architectures provide an API to enable the FPU and run
floating-point SIMD code in kernel space. However, the function names,
header locations, and semantics are inconsistent across architectures,
and FPU support may be gated behind other Kconfig options.
Provide a standard way for archite
Hi Nathan,
On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>> On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote:
>>> RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other
>>> architectures. Enabling hardware
Now that ARCH_HAS_KERNEL_FPU_SUPPORT provides a common way to compile
and run floating-point code, this test is no longer x86-specific.
Signed-off-by: Samuel Holland
---
lib/Kconfig.debug | 2 +-
lib/Makefile| 25 ++---
lib/test_fpu_glue.c | 5 -
3 files chan
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in
asm/fpu.h, so it only needs to add kernel_fpu_available() and export
the CFLAGS adjustments.
Signed-off-by: Samuel Holland
---
arch/loongarch/Kconfig | 1 +
arch/loongarch/Makefile | 5 -
arch/loongarch
PowerPC provides an equivalent to the common kernel-mode FPU API, but in
a different header and using different function names. The PowerPC API
also requires a non-preemptible context. Add a wrapper header, and
export the CFLAGS adjustments.
Signed-off-by: Samuel Holland
---
arch/powerpc/Kconfi
Christophe Leroy writes:
> Le 31/03/2023 à 12:53, Michael Ellerman a écrit :
>> "Daniel Kolesa" writes:
>>> Commit c653c591789b ("drm/amdgpu: Re-enable DCN for 64-bit powerpc")
>>> introduced this check as a workaround for the driver not building
>>> with toolchains that default to 64-bit long do
arm64 provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Signed-off-by: Samuel Holland
---
arch/arm64/Kconfig | 1 +
arch/arm64/Mak
This ensures no compiler-generated floating-point code can appear
outside kernel_fpu_{begin,end}() sections, and some architectures
enforce this separation.
Signed-off-by: Samuel Holland
---
lib/Makefile| 3 ++-
lib/{test_fpu.c => test_fpu_glue.c} | 32 +
From: Yang Guang
Convert kzalloc/memcpy operations to memdup makes for
cleaner code and avoids memcpy() failures
Signed-off-by: Chen Haonan
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/d
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Signed-off-by: Samuel Holland
---
lib/raid6/Makefile | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/lib/raid6/Makefi
This series supersedes my earier RISC-V specific series[1].
This series unifies the kernel-mode FPU API across several architectures
by wrapping the existing functions (where needed) in consistently-named
functions placed in a consistent header location, with mostly the same
semantics: they can be
ARM provides an equivalent to the common kernel-mode FPU API, but in a
different header and using different function names. Add a wrapper
header, and export CFLAGS adjustments as found in lib/raid6/Makefile.
Signed-off-by: Samuel Holland
---
arch/arm/Kconfig | 1 +
arch/arm/Makefile
Hi Christoph,
On 2023-11-22 2:33 AM, Christoph Hellwig wrote:
> On Tue, Nov 21, 2023 at 07:05:13PM -0800, Samuel Holland wrote:
>> +static inline void kernel_fpu_begin(void)
>> +{
>> +preempt_disable();
>> +fstate_save(current, task_pt_regs(current));
>> +csr_set(CSR_SSTATUS, SR_FS);
>
Now that all previously-supported architectures select
ARCH_HAS_KERNEL_FPU_SUPPORT, this code can depend on that symbol instead
of the existing list of architectures. It can also take advantage of the
common kernel-mode FPU API and method of adjusting CFLAGS.
Signed-off-by: Samuel Holland
---
d
x86 already provides kernel_fpu_begin() and kernel_fpu_end(), but in a
different header. Add a wrapper header, and export the CFLAGS
adjustments as found in lib/Makefile.
Signed-off-by: Samuel Holland
---
arch/x86/Kconfig | 1 +
arch/x86/Makefile | 20
a
Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
tree, use it instead of duplicating the flags here.
Signed-off-by: Samuel Holland
---
arch/arm/lib/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefil
Hi Christoph,
On 2023-11-22 2:40 AM, Christoph Hellwig wrote:
>> -select DRM_AMD_DC_FP if (X86 || LOONGARCH || (PPC64 && ALTIVEC) ||
>> (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
>> +select DRM_AMD_DC_FP if ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG
>> +select DRM_AMD_DC_FP if PPC64
This is motivated by the amdgpu DRM driver, which needs floating-point
code to support recent hardware. That code is not performance-critical,
so only provide a minimal non-preemptible implementation for now.
Use a similar trick as ARM to force placing floating-point code in a
separate translation
Friendly ping on this one.
Userspace side got merged, so would be great to land this patch too :)
On 02.12.23 01:17, Friedrich Vock wrote:
This improves latency if the GPU is already busy with other work.
This is useful for VR compositors that submit highly latency-sensitive
compositing work on
50 matches
Mail list logo
