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
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:
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é
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
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
---
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
-
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
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
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
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:
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
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
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
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
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
---
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
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 --
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
> ---
>
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
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
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:
>
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:
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.
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
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
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.
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
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
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
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
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
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
+
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
+
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;
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
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
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
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
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
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(),
[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
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 +
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
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 +-
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
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
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
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
Am 29.06.23 um 18:09 schrieb Xiaogang.Chen:
From: Xiaogang Chen
When kfd uses cpu to update vm iterates all current PDs/PTs bos, adds
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag and kmap them to kernel virtual
address space before kfd updates the vm that was created by gfx.
Signed-off-by:
61 matches
Mail list logo
