On Fri, Dec 8, 2023 at 1:37 PM Alex Deucher wrote:
> 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
On 2023-12-11 05:38, Christian König wrote:
Am 09.12.23 um 00:01 schrieb James Zhu:
Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.
cond_resched() is usually NAKed upstream since it is a NO-OP in most
situations.
That's weird, because
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how to do this, maybe Alex knows of hand.
Since the buffers are cleared on creation, is
On 12/11/2023 09:27, Alex Deucher wrote:
On Mon, Dec 11, 2023 at 10:20 AM Mario Limonciello
wrote:
On 12/11/2023 08:47, Christian König wrote:
Am 11.12.23 um 12:02 schrieb Hans de Goede:
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
MES provides the driver a call to explicitly flush stale process memory
within the MES to avoid a race condition that results in a fatal
memory violation.
When SET_SHADER_DEBUGGER is called, the driver passes a memory address
that represents a process context address MES uses to keep track of
Thanks for catching this.
Reviewed-by: Alex Hung
On 2023-12-08 02:58, Harshit Mogalapalli wrote:
'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:
Only schedule when hmm_range_fault returns error.
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/amdgpu_hmm.c
index
On 12/11/2023 8:42 AM, Philip Yang wrote:
On 2023-12-06 10:24, Xiaogang.Chen wrote:
From: Xiaogang Chen
v2:
-not need calculate vram page number for new registered svm range, only
do it for split vram pages.
v3:
-use dma address to calculate vram page number of split svm range;
use
PC sampling is a form of software profiling, where the threads of an application
are periodically interrupted and the program counter that the threads are
currently
attempting to execute is saved out for profiling.
The user mode code which uses this new kfd_ioctl is linked to
Am 08.12.23 um 23:53 schrieb Alex Deucher:
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
Check pcs_entry valid for pc sampling ioctl.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c | 33 ++--
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_pc_sampling.c
On 2023-12-11 10:11 AM, Christoph Hellwig wrote:
>> +#ifdef __riscv_f
>> +
>> +#define kernel_fpu_begin() \
>> +static_assert(false, "floating-point code must use a separate
>> translation unit")
>> +#define kernel_fpu_end() kernel_fpu_begin()
>> +
>> +#else
>> +
>> +void
Ping ...
On 2023-12-07 17:53, James Zhu wrote:
PC sampling is a form of software profiling, where the threads of an application
are periodically interrupted and the program counter that the threads are
currently
attempting to execute is saved out for profiling.
David Yat Sin (4):
On Mon, Dec 11, 2023 at 4:50 AM Christian König
wrote:
>
> Am 08.12.23 um 20:53 schrieb Alex Deucher:
>
> [SNIP]
>
> You also need a functionality which resets all cleared blocks to
> uncleared after suspend/resume.
>
> No idea how to do this, maybe Alex knows of hand.
>
> Since the buffers are
On 2023-12-11 05:38, Christian König wrote:
Am 09.12.23 um 00:01 schrieb James Zhu:
Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.
cond_resched() is usually NAKed upstream since it is a NO-OP in most
situations.
[JZ] then let me change back to
Hi Alex,
On 2023-12-11 9:17 AM, Alex Deucher wrote:
> On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
> wrote:
>>
>> Hi Arnd,
>>
>> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> On
> obj-$(CONFIG_TEST_FPU) += test_fpu.o
> -CFLAGS_test_fpu.o += $(FPU_CFLAGS)
> +test_fpu-y := test_fpu_glue.o test_fpu_impl.o
> +CFLAGS_test_fpu_impl.o += $(FPU_CFLAGS)
Btw, I really wonder if having a
modname-fpu += foo.o
syntax in kbuild wouldn't be preferable to this. Of coure that
On 2023-12-11 10:07 AM, Christoph Hellwig wrote:
>> +CFLAGS_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
>> +CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
>
> Btw, do we even really need the extra variables for
Looks good:
Reviewed-by: Christoph Hellwig
On Sun, Dec 10, 2023 at 5:10 AM Samuel Holland
wrote:
>
> Hi Arnd,
>
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
> > On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> >> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
> >>> On Thu, Nov 23, 2023 at 02:23:01PM +, Conor Dooley wrote:
>
Ping on this one.
On 12/5/2023 13:54, Mario Limonciello wrote:
This reverts commit ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a.
Reports are that this causes problems with external monitors after wake up
from suspend, which is something it was directly supposed to help.
Cc: Linux Regressions
Cc:
On Thu, Dec 07, 2023 at 09:54:37PM -0800, Samuel Holland wrote:
> 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_REMOVE_neon1.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon2.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon4.o += $(CC_FLAGS_NO_FPU)
> +CFLAGS_REMOVE_neon8.o += $(CC_FLAGS_NO_FPU)
Btw, do we even really need the extra variables for compiler flags
to remove? Don't gcc/clang options work
> +#ifdef __riscv_f
> +
> +#define kernel_fpu_begin() \
> + static_assert(false, "floating-point code must use a separate
> translation unit")
> +#define kernel_fpu_end() kernel_fpu_begin()
> +
> +#else
> +
> +void kernel_fpu_begin(void);
> +void kernel_fpu_end(void);
> +
> +#endif
I'll
> + * linux/arch/arm64/include/asm/fpu.h
Same comment as for arm here. Except for that:
Reviewed-by: Christoph Hellwig
> --- /dev/null
> +++ b/arch/arm/include/asm/fpu.h
> @@ -0,0 +1,17 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * linux/arch/arm/include/asm/fpu.h
Please don't add the file name to top of the file comments. It serves
no purpose and easily gets out of date.
Except for that:
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:33PM -0800, Samuel Holland wrote:
> Now that CC_FLAGS_FPU is exported and can be used anywhere in the source
> tree, use it instead of duplicating the flags here.
Looks good:
Reviewed-by: Christoph Hellwig
On Thu, Dec 07, 2023 at 09:54:36PM -0800, Samuel Holland wrote:
> 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.
Looks good:
Reviewed-by: Christoph Hellwig
Looks good:
Reviewed-by: Christoph Hellwig
On 2023-12-08 05:11, Christian König wrote:
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:
On Mon, Dec 11, 2023 at 10:20 AM Mario Limonciello
wrote:
>
> On 12/11/2023 08:47, Christian König wrote:
> > Am 11.12.23 um 12:02 schrieb Hans de Goede:
> >> Hi Wifi and AMDGPU maintainers,
> >>
> >> Here is a pull-request for the platform-drivers-x86 parts of:
> >>
> >>
On 12/11/2023 08:47, Christian König wrote:
Am 11.12.23 um 12:02 schrieb Hans de Goede:
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
From my pov the pdx86
On 2023-12-09 15:08, Mario Limonciello wrote:
> When screen brightness is rapidly changed and PSR-SU is enabled the
> display hangs on panels with this TCON even on the latest DCN 3.1.4
> microcode (0x8002a81 at this time).
>
> This was disabled previously as commit 072030b17830 ("drm/amd:
Am 11.12.23 um 12:02 schrieb Hans de Goede:
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
From my pov the pdx86 bits are ready and the
On Mon, Dec 11, 2023 at 1:22 AM Mario Limonciello
wrote:
>
> When screen brightness is rapidly changed and PSR-SU is enabled the
> display hangs on panels with this TCON even on the latest DCN 3.1.4
> microcode (0x8002a81 at this time).
>
> This was disabled previously as commit 072030b17830
[Public]
Hi all,
This week this patchset was tested on the following systems:
* Lenovo ThinkBook T13s Gen4 with AMD Ryzen 5 6600U
* MSI Gaming X Trio RX 6800
* Gigabyte Gaming OC RX 7900 XTX
These systems were tested on the following display/connection types:
*
On 2023-12-06 10:24, Xiaogang.Chen
wrote:
From: Xiaogang Chen
v2:
-not need calculate vram page number for new registered svm range, only
do it for split vram pages.
v3:
-use dma address to calculate vram page number of split svm range;
use migrate_vma
Am 11.12.23 um 08:31 schrieb Arunpravin Paneer Selvam:
Add clear page support in vram memory region.
v1:(Christian)
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
On 12/9/2023 14:08, Mario Limonciello wrote:
When screen brightness is rapidly changed and PSR-SU is enabled the
display hangs on panels with this TCON even on the latest DCN 3.1.4
microcode (0x8002a81 at this time).
This was disabled previously as commit 072030b17830 ("drm/amd: Disable
PSR-SU
From: Lijo Lazar
[ Upstream commit 81577503efb49f4ad76af22f9941d72900ef4aab ]
Check if function is implemented before making the call.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: Lijo Lazar
[ Upstream commit 81577503efb49f4ad76af22f9941d72900ef4aab ]
Check if function is implemented before making the call.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
Hi Samuel,
Thanks for trying to clean all this up.
One problem below.
Samuel Holland writes:
> 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
Hi Wifi and AMDGPU maintainers,
Here is a pull-request for the platform-drivers-x86 parts of:
https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
>From my pov the pdx86 bits are ready and the
>platform-drivers-x86-amd-wbrf-v6.8-1 tag can be merged by you to
Hi,
> Here is a pull-request for the platform-drivers-x86 parts of:
>
> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
>
> From my pov the pdx86 bits are ready and the
> platform-drivers-x86-amd-wbrf-v6.8-1 tag can be merged by you to merge the
>
Hi Johannes,
On 12/11/23 12:41, Johannes Berg wrote:
> Hi,
>
>> Here is a pull-request for the platform-drivers-x86 parts of:
>>
>> https://lore.kernel.org/platform-driver-x86/20231211100630.2170152-1-jun@amd.com/
>>
>> From my pov the pdx86 bits are ready and the
>>
From: Ivan Lipski
[ Upstream commit 3d71a8726e05a35beb9de394e86ce896d69e563f ]
[WHY]
Some eDP panels's ext caps don't write initial value cause the value of
dpcd_addr(0x317) is random. It means that sometimes the eDP will
clarify it is OLED, miniLED...etc cause the backlight control interface
From: Alvin Lee
[ Upstream commit fec05adc40c25a028c9dfa9d540f800a2d433f80 ]
VBIOS has suggested to use channel_width=2 for any ASIC that uses vram
info 3.0. This is because channel_width in the vram table no longer
represents the memory width
Tested-by: Daniel Wheeler
Reviewed-by: Samson Tam
From: Lijo Lazar
[ Upstream commit 81577503efb49f4ad76af22f9941d72900ef4aab ]
Check if function is implemented before making the call.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
Acked-by: Alex Deucher
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
From: Ivan Lipski
[ Upstream commit 3d71a8726e05a35beb9de394e86ce896d69e563f ]
[WHY]
Some eDP panels's ext caps don't write initial value cause the value of
dpcd_addr(0x317) is random. It means that sometimes the eDP will
clarify it is OLED, miniLED...etc cause the backlight control interface
From: Alvin Lee
[ Upstream commit fec05adc40c25a028c9dfa9d540f800a2d433f80 ]
VBIOS has suggested to use channel_width=2 for any ASIC that uses vram
info 3.0. This is because channel_width in the vram table no longer
represents the memory width
Tested-by: Daniel Wheeler
Reviewed-by: Samson Tam
Am 10.12.23 um 19:24 schrieb Woody Suwalski:
Hello, it has been now over 2 weeks and I have not seen any response
to this patch.
Has it been lost in the cracks of the wide internet ? :-(
Well your patch is malformed ("#" before each line in the commit
message) and probably ended up being
Am 09.12.23 um 00:01 schrieb James Zhu:
Needn't do schedule for each hmm_range_fault, and use cond_resched
to replace schedule.
cond_resched() is usually NAKed upstream since it is a NO-OP in most
situations.
IIRC there was even a patch set to completely remove it.
Christian.
Hi all,
Compared with the previous version(v15), only patch 1 was modified to fix
compilation errors,
and other patches remained the same as the previous version.
Regards,
Ma Jun
On 12/11/2023 6:06 PM, Ma Jun wrote:
> Due to electrical and mechanical constraints in certain platform designs
From: Evan Quan
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
Signed-off-by: Ma Jun
--
v10->v11:
- downgrade the prompt level on message failure(Lijo)
v13:
- Fix the format issue (IIpo Jarvinen)
- Remove duplicate
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Co-developed-by: Evan Quan
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
Signed-off-by: Ma Jun
--
v10->v11:
- downgrade the prompt level on message failure(Lijo)
v13:
- Fix the format issue (IIpo Jarvinen)
- Move
From: Evan Quan
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
Signed-off-by: Ma Jun
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 29 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 30
From: Evan Quan
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
Signed-off-by: Ma Jun
v13:
- Move some struct variables to amdgpu_smu.h to reduce
duplicate code
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
From: Evan Quan
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
Signed-off-by: Evan Quan
From: Evan Quan
To support the WBRF mechanism, Wifi adapters utilized in the system must
register the frequencies in use (or unregister those frequencies no longer
used) via the dedicated calls. So that, other drivers responding to the
frequencies can take proper actions to mitigate possible
From: Evan Quan
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
Signed-off-by: Ma Jun
Reviewed-by: Mario Limonciello
--
v8->v9:
- correct typo(Mhz -> MHz) (Johnson)
v13:
- Fix the format issue (IIpo Jarvinen)
---
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices
Add documentation about AMD's Wifi band RFI mitigation (WBRF) mechanism
explaining the theory and how it is used.
Signed-off-by: Ma Jun
Reviewed-by: Hans de Goede
Reviewed-by: Mario Limonciello
--
v16:
- Fix the compile warnnings
---
Documentation/driver-api/index.rst | 1 +
Due to electrical and mechanical constraints in certain platform designs there
may be likely interference of relatively high-powered harmonics of the (G-)DDR
memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To
mitigate possible RFI interference we introuduced WBRF(Wifi
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how to do this, maybe Alex knows of hand.
Since the buffers are cleared on creation, is there actually anything to do?
Well exactly
Hi Arnd,
On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
>> 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:
On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
> 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
Hello, it has been now over 2 weeks and I have not seen any response to
this patch.
Has it been lost in the cracks of the wide internet ? :-(
Thanks, Woody
Woody Suwalski wrote:
# Fix to avoid multiple error lines printed on every suspend by Radeon
driver's debugfs.
#
#
On Sat, Dec 9, 2023, at 22:29, Samuel Holland wrote:
> On 2023-12-09 2:38 PM, Arnd Bergmann wrote:
>> On Fri, Dec 8, 2023, at 06:04, Samuel Holland wrote:
>>> On 2023-11-29 6:42 PM, Nathan Chancellor wrote:
https://lore.kernel.org/20231019205117.GA839902@dev-arch.thelio-3990X/
>>>
>>> I
69 matches
Mail list logo
