Re: [PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

Am 03.07.23 um 14:35 schrieb Arnd Bergmann: From: Arnd Bergmann On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type

RE: [PATCH 3/3] drm/amdgpu: Issue ras enable_feature for gfx ip only

[AMD Official Use Only - General] The series is: Reviewed-by: Tao Zhou > -Original Message- > From: Zhang, Hawking > Sent: Monday, July 3, 2023 4:56 PM > To: amd-gfx@lists.freedesktop.org; Zhou1, Tao ; Yang, > Stanley ; Chai, Thomas ; Li, > Candice > Cc: Zhang, Hawking > Subject: [PA

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

On 7/3/23 22:40, Quan, Evan wrote: [AMD Official Use Only - General] -Original Message- From: Limonciello, Mario Sent: Saturday, July 1, 2023 12:41 AM To: Quan, Evan ; raf...@kernel.org; l...@kernel.org; Deucher, Alexander ; Koenig, Christian ; Pan, Xinhui ; airl...@gmail.com; dan...@f

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Simon Horman > Sent: Friday, June 30, 2023 9:39 PM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Limonciello, Mario > Sent: Saturday, July 1, 2023 12:41 AM > To: Quan, Evan ; raf...@kernel.org; l...@kernel.org; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsol

[PATCH] drm/amdgpu: Change golden settings for GFX v9.4.3

Change the settings applicable for A0. GRBM_MCM_ADDR setting will be applied by firmware. Signed-off-by: Lijo Lazar --- drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c b/drivers/gpu/drm/am

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:20 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:25 AM > To: Limonciello, Mario > Cc: Quan, Evan ; raf...@kernel.org; l...@kernel.org; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.c

RE: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD

[AMD Official Use Only - General] > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 8:51 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan...@sipsoluti

RE: [PATCH V5 4/9] wifi: mac80211: Add support for ACPI WBRF

[AMD Official Use Only - General] Hi Andrew, > -Original Message- > From: Andrew Lunn > Sent: Saturday, July 1, 2023 9:02 AM > To: Quan, Evan > Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; johan.

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, Jul 3, 2023, 22:38 Randy Dunlap wrote: > > > On 7/3/23 19:34, Marek Olšák wrote: > > > > > > On Mon, Jul 3, 2023, 03:12 Michel Dänzer > wrote: > > > > Marek, > Please stop sending html emails to the mailing lists. > The mailing list software drops them.

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, Jul 3, 2023, 03:12 Michel Dänzer wrote: > On 6/30/23 22:32, Marek Olšák wrote: > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer < > michel.daen...@mailbox.org > wrote: > >> On 6/30/23 16:59, Alex Deucher wrote: > >>> On Fri, Jun 30, 2023 at 10:49 AM Se

Re: [PATCH v7 2/8] PCI/VGA: Deal only with VGA class devices

Hi, On 2023/6/16 22:34, Alex Deucher wrote: On Fri, Jun 16, 2023 at 10:22 AM Sui Jingfeng wrote: On 2023/6/16 21:41, Alex Deucher wrote: On Fri, Jun 16, 2023 at 3:11 AM Sui Jingfeng wrote: Hi, On 2023/6/16 05:11, Alex Deucher wrote: On Wed, Jun 14, 2023 at 6:50 AM Sui Jingfeng wrote: H

Re: [PATCH v4 6/6] drm/doc: Define KMS atomic state set

Em 03/07/2023 05:38, Pekka Paalanen escreveu: On Fri, 30 Jun 2023 23:09:17 -0300 André Almeida wrote: Specify how the atomic state is maintained between userspace and kernel, plus the special case for async flips. Signed-off-by: André Almeida [...] If you want to take these and need

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

Em 03/07/2023 05:49, Pekka Paalanen escreveu: On Mon, 3 Jul 2023 09:12:29 +0200 Michel Dänzer wrote: On 6/30/23 22:32, Marek Olšák wrote: On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer mailto:michel.daen...@mailbox.org>> wrote: On 6/30/23 16:59, Alex Deucher wrote: On Fri, Jun 30, 2023 a

[PATCH] drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar()

From: Arnd Bergmann On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is alw

Re: [PATCH 0/6] Clean up patches in amdgpu/gmc_*.c

Acked-by: Christian König for the entire series. Am 30.06.23 um 17:55 schrieb 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

[PATCH 3/3] drm/amdgpu: Issue ras enable_feature for gfx ip only

For non-GFX IP blocks, set up ras obj if ras feature is allowed. For GFX IP blocks, force issue ras enable_feature command to firmware and only set up ras obj if ras feature is allowed Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 30 + 1 file

[PATCH 2/3] drm/amdgpu: Remove gfx v11_0_3 ras_late_init call

amdgpu_ras_late_init will invoke ras_late_init call per IP block Signed-off-by: Hawking Zhang --- drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 26 -- 1 file changed, 26 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c

[PATCH 1/3] drm/amdgpu: Apply poison mode check to GFX IP only

For GFX IP that only supports poison consumption, GFX RAS won't be marked as enabled. i.e., hardware doesn't support gfx sram ecc. But driver still needs to issue firmware to enable poison consumption mode for GFX IP. In such case, check poison mode and treat GFX IP as RAS capable IP block. Signed

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On Mon, 3 Jul 2023 09:12:29 +0200 Michel Dänzer wrote: > On 6/30/23 22:32, Marek Olšák wrote: > > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer > > wrote: > >> On 6/30/23 16:59, Alex Deucher wrote: > >>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick > >>

Re: [PATCH v4 6/6] drm/doc: Define KMS atomic state set

On Fri, 30 Jun 2023 23:09:17 -0300 André Almeida wrote: > 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 +++ >

[PATCH v2 4/6] drm/radeon: Implement the is_boot_device callback function

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

[PATCH v2 5/6] drm/i915: Implement the is_boot_device callback function

From: Sui Jingfeng This patch add a function to identify if a device is the default boot selected by the firmware, it require the GPU has firmware framebuffer driver support (such as efifb). If a specific hardware doesn't have firmware framebuffer support, then the introduced function will just r

[PATCH] Revert "drm/amd/display: Program OTG vtotal min/max selectors unconditionally for DCN1+"

This reverts commit 06c3a652a787efc960af7c8816036d25c4227c6c. After this commit, the Steam Deck cannot boot with graphics anymore; the following message is observed on dmesg: "[drm] ERROR [CRTC:67:crtc-0] flip_done timed out" No other error is observed, it just stays like that. After bisecting a

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

> Drivers/subsystems contributing frequencies: > > 1) During probe, check `wbrf_supported_producer` to see if WBRF supported >for the device. What is the purpose of this stage? Why would it not be supported for this device? > +#ifdef CONFIG_WBRF > +bool wbrf_supported_producer(struct device

Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF mitigations

> Right now there are stubs for non CONFIG_WBRF as well as other patches are > using #ifdef CONFIG_WBRF or having their own stubs. Like mac80211 patch > looks for #ifdef CONFIG_WBRF. > > I think we should pick one or the other. > > Having other subsystems #ifdef CONFIG_WBRF will make the series

[PATCH v2 3/6] drm/amdgpu: Implement the is_boot_device callback function

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

[PATCH v2 6/6] drm/ast: Register as a vga client to vgaarb by calling vga_client_register()

From: Sui Jingfeng Becasuse the VGA Display Controller in the ASpeed BMC chip is also a PCIe device, the Software Programming guide of AST2400 say that it is Fully IBM VGA compliant, thus, it should also particiate in the arbitration. Cc: Thomas Zimmermann Cc: Jocelyn Falempe Cc: David Airlie

[PATCH v2 0/6] PCI/VGA: Improve the default VGA device selection

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

Re: [PATCH V5 2/9] driver core: add ACPI based WBRF mechanism introduced by AMD

> + argv4 = kzalloc(sizeof(*argv4) * (2 * num_of_ranges + 2 + 1), > GFP_KERNEL); > + if (!argv4) > + return -ENOMEM; > + > + argv4[arg_idx].package.type = ACPI_TYPE_PACKAGE; > + argv4[arg_idx].package.count = 2 + 2 * num_of_ranges; > + argv4[arg_idx++].package.eleme

[PATCH v2 2/6] PCI/VGA: Improve the default VGA device selection

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

[PATCH v2 1/6] video/aperture: Add a helper to detect if an aperture contains firmware FB

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

Re: [PATCH V5 4/9] wifi: mac80211: Add support for ACPI WBRF

> +static void get_chan_freq_boundary(u32 center_freq, > +u32 bandwidth, > +u64 *start, > +u64 *end) > +{ > + bandwidth = MHZ_TO_KHZ(bandwidth); > + center_freq = MHZ_TO_KHZ(center_freq); > + > +

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

On 6/30/23 22:32, Marek Olšák wrote: > On Fri, Jun 30, 2023 at 11:11 AM Michel Dänzer > wrote: >> On 6/30/23 16:59, Alex Deucher wrote: >>> On Fri, Jun 30, 2023 at 10:49 AM Sebastian Wick >>> mailto:sebastian.w...@redhat.com>> wrote: On Tue, Jun 27, 2023 at