Specify how the atomic state is maintained between userspace and
kernel, plus the special case for async flips.
Signed-off-by: André Almeida
---
v4: new patch
---
Documentation/gpu/drm-uapi.rst | 19 +++
1 file changed, 19 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rs
Given that prop changes may lead to modesetting, which would defeat the
fast path of the async flip, refuse any atomic prop change for async
flips in atomic API. The only exceptions are the framebuffer ID to flip
to and the mode ID, that could be referring to an identical mode.
Signed-off-by: Andr
From: Simon Ser
amdgpu_dm_commit_planes() already sets the flip_immediate flag for
async page-flips. This flag is used to set the UNP_FLIP_CONTROL
register. Thus, no additional change is required to handle async
page-flips with the atomic uAPI.
Signed-off-by: Simon Ser
Reviewed-by: André Almeid
From: Simon Ser
This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.
All atomic drivers setting drm_mode_config.async_page_flip are updated
to also
From: Simon Ser
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by:
From: Simon Ser
If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.
Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back
Hi,
This work from me and Simon adds support for DRM_MODE_PAGE_FLIP_ASYNC through
the atomic API. This feature is already available via the legacy API. The use
case is to be able to present a new frame immediately (or as soon as
possible), even if after missing a vblank. This might result in teari
On Fri, Jun 30, 2023 at 5:27 PM Mario Limonciello
wrote:
>
> This was accidentally lost by commit e6e3bee0bc9a3 ("drm/amd: Use
> attribute groups for PSP flashing attributes")
>
> Fixes: e6e3bee0bc9a ("drm/amd: Use attribute groups for PSP flashing
> attributes")
> Reported-by: likun@amd.com
This was accidentally lost by commit e6e3bee0bc9a3 ("drm/amd: Use
attribute groups for PSP flashing attributes")
Fixes: e6e3bee0bc9a ("drm/amd: Use attribute groups for PSP flashing
attributes")
Reported-by: likun@amd.com
Signed-off-by: Mario Limonciello
---
drivers/gpu/drm/amd/amdgpu/amdgp
That's a terrible idea. Ignoring API calls would be identical to a freeze.
You might as well disable GPU recovery because the result would be the same.
There are 2 scenarios:
- robust contexts: report the GPU reset status and skip API calls; let the
app recreate the context to recover
- non-robust
On Fri, 30 Jun 2023, Bjorn Helgaas wrote:
> On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote:
>> On 2023/6/30 01:44, Limonciello, Mario wrote:
>> > > On 2023/6/29 23:54, Bjorn Helgaas wrote:
>> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
>
>> > > > 4) Right now w
Hi Dave, Daniel,
Fixes for 6.5. This is a bit bigger than usual since it's two weeks of fixes
and I missed a bunch of stuff for 6.4 final due to being out of the office
last week and having a late PR.
The following changes since commit dcb0775d36de28992f56455ab3967b30d380:
Merge tag 'drm-
On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote:
> On 2023/6/30 01:44, Limonciello, Mario wrote:
> > > On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> > > > 4) Right now we're in the middle of the v6.5 merge window, so ne
On 6/30/2023 05:32, Evan Quan wrote:
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
Fix below checkpatch error & warnings:
ERROR: that open brace { should be on the previous line
WARNING: static const char * array should probably be static const char * const
WARNING: Block comments use * on subsequent lines
WARNING: Block comments use a trailing */ on a separate line
Cc: Christ
Fix below checkpatch warnings:
WARNING: else is not generally useful after a break or return
+ return true;
+ } else {
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
1 file changed, 5 inserti
Fix below checkpatch error & warnings:
ERROR: trailing statements should be on next line
+ default: BUG();
WARNING: braces {} are not necessary for single statement blocks
WARNING: braces {} are not necessary for any arm of this statement
WARNING: Block comments should align the * on each l
Fix below checkpatch warnings:
WARNING: quoted string split across lines
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: void function return statements are not generally useful
WARNING: braces {} are not necessary for any arm of this statement
Cc: Christian König
Cc: Alex Deuc
Fix below checkpatch errors & warnings:
ERROR: trailing statements should be on next line
+ default: BUG();
ERROR: trailing statements should be on next line
WARNING: braces {} are not necessary for single statement blocks
WARNING: braces {} are not necessary for any arm of this statement
W
Fix below checkpatch warnings:
WARNING: Consider removing the code enclosed by this #if 0 and its #endif
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: quoted string split across lines
Cc: Christian König
Cc: Alex Deucher
Signed-off-by: Srinivasan Shanmugam
---
drivers/gpu/
Srinivasan Shanmugam (6):
drm/amdgpu: Fix warnings in gmc_v10_0.c
drm/amdgpu: Fix warnings in gmc_v11_0.c
drm/amdgpu: Fix errors & warnings in gmc_ v6_0, v7_0.c
drm/amdgpu: Fix error & warnings in gmc_v8_0.c
drm/amdgpu: Remove else after return statement in
'gmc_v8_0_check_soft_reset'
Add RLCG interface support for gfx v9.4.3 and multiple XCCs.
Do not enable it yet.
Signed-off-by: Victor Lu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 17 --
drivers/gpu/drm/amd/amdg
On Thu, Jun 29, 2023 at 8:05 PM Sreekant Somasekharan
wrote:
>
> Include kgd_gfx_v9_get_cu_occupancy call inside kfd2kgd_calls for
> GFX9.4.3 to expose cu_occupancy sysfs file.
>
> Signed-off-by: Sreekant Somasekharan
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_
On Fri, Jun 30, 2023 at 4:59 PM Alex Deucher wrote:
>
> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
> wrote:
> >
> > On Tue, Jun 27, 2023 at 3:23 PM André Almeida
> > wrote:
> > >
> > > Create a section that specifies how to deal with DRM device resets for
> > > kernel and userspace drivers
On Fri, Jun 30, 2023 at 7:22 AM Yang Wang wrote:
>
> the dceflck sysnode is not aviable on GFX v9.4.3 chip.
>
> Signed-off-by: Yang Wang
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
On 6/30/23 16:59, Alex Deucher wrote:
> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
> wrote:
>> On Tue, Jun 27, 2023 at 3:23 PM André Almeida wrote:
>>>
>>> +Robustness
>>> +--
>>> +
>>> +The only way to try to keep an application working after a reset is if it
>>> +complies with the
On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick
wrote:
>
> On Tue, Jun 27, 2023 at 3:23 PM André Almeida wrote:
> >
> > Create a section that specifies how to deal with DRM device resets for
> > kernel and userspace drivers.
> >
> > Acked-by: Pekka Paalanen
> > Signed-off-by: André Almeida
> >
On Tue, Jun 27, 2023 at 3:23 PM André Almeida wrote:
>
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Acked-by: Pekka Paalanen
> Signed-off-by: André Almeida
> ---
>
> v4:
> https://lore.kernel.org/lkml/20230626183347.55118-1-andreal
On Fri, Jun 30, 2023 at 10:25 AM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Fri, Jun 30, 2023 at 10:34 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
> >
> > On Tue, May 30, 2023 at 06:23:53AM +, Zhu, Jiadong wrote:
> > > -Original Message-
> > > From: Zhu, Jiadong
> > > Sent: Fr
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
bec
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
aperture_remove_confl
From: Sui Jingfeng
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Ba
From: Sui Jingfeng
[why]
The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is
arch-dependent, it's a dummy on non-x86 architectures currently.
This made VGAARB lost an important condition for the arbitration.
It could still be wrong even if we remove the #ifdef and #endif guards.
bec
On Fri, Jun 30, 2023 at 10:34 PM Hyeonggon Yoo <42.hye...@gmail.com> wrote:
>
> On Tue, May 30, 2023 at 06:23:53AM +, Zhu, Jiadong wrote:
> > -Original Message-
> > From: Zhu, Jiadong
> > Sent: Friday, May 26, 2023 9:19 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Zhu, Jiadong
> >
From: Sui Jingfeng
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Ba
On Fri, Jun 30, 2023 at 06:32:32PM +0800, Evan Quan wrote:
...
> diff --git a/include/linux/wbrf.h b/include/linux/wbrf.h
> new file mode 100644
> index ..3ca95786cef5
> --- /dev/null
> +++ b/include/linux/wbrf.h
> @@ -0,0 +1,65 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + *
Am 30.06.23 um 13:56 schrieb Srinivasan Shanmugam:
Fix the below checkpatch warnings:
WARNING: Block comments should align the * on each line
+ /*
+ * Raven2 has a HW issue that it is unable to use the
WARNING: Prefer 'unsigned int' to bare use of 'un
Fix the below checkpatch errors & warnings:
ERROR: that open brace { should be on the previous line
ERROR: space prohibited before that ',' (ctx:WxV)
ERROR: space required after that ',' (ctx:WxV)
ERROR: code indent should use tabs where possible
ERROR: switch and case should be at the same indent
Fix below checkpatch warnings:
WARNING: else is not generally useful after a break or return
+ return true;
+ } else {
WARNING: else is not generally useful after a break or return
+ return true;
+ } else {
Cc: Christian Kön
Fix the below checkpatch warnings:
WARNING: static const char * array should probably be static const char * const
+static const char *gfxhub_client_ids[] = {
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+ unsigned i;
WARNING: static const char * array should probably be static
Fix the below checkpatch warnings:
WARNING: static const char * array should probably be static const char * const
+static const char *gfxhub_client_ids[] = {
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+ unsigned i;
WARNING: Missing a blank line after declarations
+ int
Fix the below checkpatch warnings:
WARNING: static const char * array should probably be static const char * const
+static const char *gfxhub_client_ids[] = {
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+ unsigned i;
WARNING: Missing a blank line after declarations
+ u32
Fix the below checkpatch warnings:
WARNING: Block comments should align the * on each line
+ /*
+ * Raven2 has a HW issue that it is unable to use the
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
+ unsigned num_level, block_size;
WARN
Srinivasan Shanmugam (6):
drm/amdgpu: Fix warnings in gfxhub_ v1_0, v1_2.c
drm/amdgpu: Fix warnings in gfxhub_v2_0.c
drm/amdgpu: Fix warnings in gfxhub_v2_1.c
drm/amdgpu: Fix warnings in gfxhub_ v3_0, v3_0_3.c
drm/amdgpu: Fix errors & warnings in gfx_v10_0.c
drm/amdgpu: Remove else afte
Am 20.06.23 um 15:29 schrieb Horace Chen:
[Why]
VCN will use some framebuffer space as its cache. It needs to
be reset when reset happens, such as FLR. Otherwise some error
may be kept after the reset.
Well this doesn't make sense at all.
The full content of adev->vcn.inst[i].cpu_addr is saved
the dceflck sysnode is not aviable on GFX v9.4.3 chip.
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 9ef88a0b1b57..5bf401533103 1
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is device-ag
Currently, the default VGA device selection is not perfect. Potential
problems are:
1) This function is a no-op on non-x86 architectures.
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is device-ag
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately due to the fact that apertures list will be
freed dynamically, the location and size information of the firmware fb
will be lost after dedicated drivers call
aperture_remove_conflicting_devices(),
ape
[AMD Official Use Only - General]
Hi Rafael & Andrew,
I just posted a new V5 series based on the discussions here and offline
discussions with Mario.
Please share your comments/insights there.
Thanks,
Evan
> -Original Message-
> From: Rafael J. Wysocki
> Sent: Saturday, June 24, 2023 1
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h | 3 +-
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 3 +
.../gpu/d
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 30 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/dr
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
Reviewed-by: Mario
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
.../amd/pm/swsmu/inc/pmfw
To support AMD's WBRF interference mitigation mechanism, Wifi adapters
utilized in the system must register the frequencies in use(or unregister
those frequencies no longer used) via the dedicated APCI calls. So that,
other drivers responding to the frequencies can take proper actions to
mitigate p
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index
AMD has introduced an ACPI based mechanism to support WBRF for some
platforms with AMD dGPU + WLAN. This needs support from BIOS equipped
with necessary AML implementations and dGPU firmwares.
For those systems without the ACPI mechanism and developing solutions,
user can use the generic WBRF solu
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 can
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 producers can advertise th
60 matches
Mail list logo
