Re: [PATCH v3 04/12] PCI: Drop the `is_thunderbolt` attribute from PCI core

2022-02-13 Thread Limonciello, Mario
On 2/13/2022 02:20, Lukas Wunner wrote: On Fri, Feb 11, 2022 at 01:32:42PM -0600, Mario Limonciello wrote: The `is_thunderbolt` attribute is currently a dumping ground for a variety of things. It's not as arbitrary as it may seem. Quite a bit of thought went into the current design.

RE: [PATCH v2 4/9] PCI: mark USB4 devices as removable

2022-02-11 Thread Limonciello, Mario
[Public] > -Original Message- > From: Mika Westerberg > Sent: Friday, February 11, 2022 04:35 > To: Limonciello, Mario > Cc: Bjorn Helgaas ; Andreas Noever > ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open list:THUNDERBOLT DRIVER u...@vger.kernel.o

RE: [PATCH v2 3/9] PCI: drop `is_thunderbolt` attribute

2022-02-11 Thread Limonciello, Mario
[Public] > -Original Message- > From: Mika Westerberg > Sent: Friday, February 11, 2022 04:24 > To: Limonciello, Mario > Cc: Bjorn Helgaas ; Andreas Noever > ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open list:THUNDERBOLT DRIVER u...@vger.kernel.o

Re: [PATCH v3 03/12] PCI: Move check for old Apple Thunderbolt controllers into a quirk

2022-02-11 Thread Limonciello, Mario
On 2/11/2022 15:35, Bjorn Helgaas wrote: On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote: `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt controller to indicate that D3 is possible. As this is used solely for older Apple systems, move it into a quirk

Re: [PATCH v4 00/10] Overhaul `is_thunderbolt`

2022-02-16 Thread Limonciello, Mario
On 2/16/2022 08:44, Alex Deucher wrote: On Wed, Feb 16, 2022 at 9:34 AM Mika Westerberg wrote: Hi all, On Tue, Feb 15, 2022 at 01:07:00PM -0600, Limonciello, Mario wrote: On 2/15/2022 01:29, Lukas Wunner wrote: On Mon, Feb 14, 2022 at 06:01:50PM -0600, Mario Limonciello wrote: drivers

RE: [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

2022-02-28 Thread Limonciello, Mario
[AMD Official Use Only] > > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote: > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external- > facing" > > assumption above. Not having a Thunderbolt spec, I have no idea how > > you deal with that. > > You can download the

RE: [PATCH v5 3/7] PCI: Drop the `is_thunderbolt` attribute from PCI core

2022-02-28 Thread Limonciello, Mario
[AMD Official Use Only] > -Original Message- > From: Lukas Wunner > Sent: Monday, February 28, 2022 16:33 > To: Bjorn Helgaas > Cc: Limonciello, Mario ; Mika Westerberg > ; Michael Jamet > ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open li

Re: [PATCH v4 00/10] Overhaul `is_thunderbolt`

2022-02-15 Thread Limonciello, Mario
On 2/15/2022 01:29, Lukas Wunner wrote: On Mon, Feb 14, 2022 at 06:01:50PM -0600, Mario Limonciello wrote: drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +- drivers/gpu/drm/amd/amdgpu/nbio_v2_3.c | 2 +- drivers/gpu/drm/nouveau/nouveau_vga.c | 4 +-

RE: [PATCHv2] drm/amdgpu: disable ASPM on Intel AlderLake based systems

2022-04-08 Thread Limonciello, Mario
[Public] > -Original Message- > From: Alex Deucher > Sent: Friday, April 8, 2022 14:09 > To: Gong, Richard > Cc: Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; Dave Airlie > ; Daniel Vetter ; Limonciello, Mario > ; Maling list - DRI developers de.

RE: [PATCH] drm/amdgpu: disable ASPM for legacy products that don't support ASPM

2022-04-08 Thread Limonciello, Mario
[Public] > -Original Message- > From: Gong, Richard > Sent: Friday, April 8, 2022 11:20 > To: Limonciello, Mario ; Deucher, Alexander > ; Koenig, Christian > ; Pan, Xinhui ; > airl...@linux.ie; dan...@ffwll.ch > Cc: amd-...@lists.freedesktop.org; dri-devel@list

RE: [PATCH] drm/amdgpu: disable ASPM for legacy products that don't support ASPM

2022-04-08 Thread Limonciello, Mario
top.org; linux- > ker...@vger.kernel.org; Limonciello, Mario ; > Gong, Richard > Subject: [PATCH] drm/amdgpu: disable ASPM for legacy products that don't > support ASPM > > Active State Power Management (ASPM) feature is enabled since kernel > 5.14. > However there are some legacy product

RE: [PATCH] drm/amdgpu: Ensure HDA function is suspended before ASIC reset

2022-04-07 Thread Limonciello, Mario
t; gfx list ; Chiu, Solomon > ; Limonciello, Mario > ; Quan, Evan ; > Tuikov, Luben > Subject: Re: [PATCH] drm/amdgpu: Ensure HDA function is suspended > before ASIC reset > > On Thu, Apr 7, 2022 at 8:21 AM Kai-Heng Feng > wrote: > > > > DP/HDMI audio on AMD PR

RE: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

2022-04-13 Thread Limonciello, Mario
[Public] > On Wed, Apr 13, 2022 at 3:43 AM Paul Menzel > wrote: > > > > Dear Richard, > > > > > > Thank you for sending out v4. > > > > Am 12.04.22 um 23:50 schrieb Richard Gong: > > > Active State Power Management (ASPM) feature is enabled since kernel > 5.14. > > > There are some AMD GFX

RE: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based systems

2022-04-20 Thread Limonciello, Mario
exander ; Koenig, Christian > ; Limonciello, Mario > > Subject: Re: [PATCHv4] drm/amdgpu: disable ASPM on Intel Alder Lake based > systems > > On Wed, Apr 20, 2022 at 5:02 PM Paul Menzel > wrote: > > > > Dear Richard, > > > > > > Am 20.04.22 um

RE: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks

2022-07-13 Thread Limonciello, Mario
[Public] > -Original Message- > From: Werner Sembach > Sent: Wednesday, July 13, 2022 12:08 > To: Hans de Goede ; Ben Skeggs > ; Karol Herbst ; Lyude > ; Daniel Dadap ; Maarten > Lankhorst ; Maxime Ripard > ; Thomas Zimmermann ; > Jani Nikula ; Joonas Lahtinen > ; Rodrigo Vivi ; >

RE: [PATCHv5] drm/amdgpu: vi: disable ASPM on Intel Alder Lake based systems

2022-05-02 Thread Limonciello, Mario
l test robot ; LKML ker...@vger.kernel.org>; Maling list - DRI developers de...@lists.freedesktop.org>; Limonciello, Mario > > Subject: Re: [PATCHv5] drm/amdgpu: vi: disable ASPM on Intel Alder Lake > based systems > > Reviewed-by: Alex Deucher > > On Fri, Apr 29, 2022 at 1

Re: [PATCH] drm: amd: amdgpu: ACPI: Add comment about ACPI_FADT_LOW_POWER_S0

2022-08-25 Thread Limonciello, Mario
On 8/24/2022 12:32, Rafael J. Wysocki wrote: From: Rafael J. Wysocki According to the ACPI specification [1], the ACPI_FADT_LOW_POWER_S0 flag merely means that it is better to use low-power S0 idle on the given platform than S3 (provided that the latter is supported) and it doesn't preclude

Re: [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)

2022-10-25 Thread Limonciello, Mario
On 10/25/2022 15:25, Hans de Goede wrote: Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: That is a valid point, but keep in mind that this is only used on ACPI platforms and then only on devices with a builtin LCD panel

RE: [PATCH v6 20/45] drm/amd: Parse both v1 and v2 TA microcode headers using same function

2023-01-05 Thread Limonciello, Mario
[AMD Official Use Only - General] > -Original Message- > From: Lazar, Lijo > Sent: Thursday, January 5, 2023 07:22 > To: Limonciello, Mario ; Deucher, Alexander > ; linux-ker...@vger.kernel.org > Cc: Javier Martinez Canillas ; Carlos Soriano Sanchez > ; amd-...@

RE: [PATCH v4 27/27] drm/amd: Optimize SRIOV switch/case for PSP microcode load

2023-01-04 Thread Limonciello, Mario
[Public] > -Original Message- > From: Christian König > Sent: Wednesday, January 4, 2023 07:18 > To: Limonciello, Mario ; Deucher, Alexander > ; linux-ker...@vger.kernel.org > Cc: Pan, Xinhui ; Lazar, Lijo ; > Javier Martinez Canillas ; dri- > de...@li

RE: [PATCH v5 10/45] drm/amd: Load VCN microcode during early_init

2023-01-04 Thread Limonciello, Mario
[Public] > -Original Message- > From: Alex Deucher > Sent: Wednesday, January 4, 2023 11:16 > To: Limonciello, Mario > Cc: Deucher, Alexander ; linux- > ker...@vger.kernel.org; Pan, Xinhui ; Lazar, Lijo > ; Javier Martinez Canillas ; dri- > de...@li

RE: Coverity: dm_dmub_sw_init(): Incorrect expression

2023-01-12 Thread Limonciello, Mario
[AMD Official Use Only - General] This particular one was fixed already in https://patchwork.freedesktop.org/patch/518050/ which got applied today. > -Original Message- > From: coverity-bot > Sent: Thursday, January 12, 2023 16:25 > To: Limonciello, Mario >

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-01-12 Thread Limonciello, Mario
On 1/12/2023 02:50, Wayne Lin wrote: This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. [Why] Changes cause regression on amdgpu mst. E.g. In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload one by one and call fill_dc_mst_payload_table_from_drm() to update

RE: [PATCH v7 20/45] drm/amd: Parse both v1 and v2 TA microcode headers using same function

2023-01-09 Thread Limonciello, Mario
[AMD Official Use Only - General] > -Original Message- > From: Lazar, Lijo > Sent: Thursday, January 5, 2023 21:27 > To: Limonciello, Mario ; Deucher, Alexander > ; linux-ker...@vger.kernel.org > Cc: Javier Martinez Canillas ; Carlos Soriano Sanchez > ; amd-...@

Re: [v3] drm/amdgpu/mst: Stop ignoring error codes and deadlocking

2022-11-18 Thread Limonciello, Mario
On 11/18/2022 13:25, Lyude Paul wrote: It appears that amdgpu makes the mistake of completely ignoring the return values from the DP MST helpers, and instead just returns a simple true/false. In this case, it seems to have come back to bite us because as a result of simply returning false from

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-01-13 Thread Limonciello, Mario
On 1/13/2023 13:28, Lyude Paul wrote: On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote: On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote: Cc: intel-gfx, drm maintainers Please have the courtesy of Cc'ing us for changes impacting us, and maybe try to involve us earlier

RE: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Limonciello, Mario
[Public] > -Original Message- > From: Alex Deucher > Sent: Monday, January 16, 2023 15:42 > To: Guilherme G. Piccoli > Cc: amd-...@lists.freedesktop.org; Jiang, Sonny ; > ker...@gpiccoli.net; Pan, Xinhui ; dri- > de...@lists.freedesktop.org; Lazar, Lijo ; Limoncie

Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Limonciello, Mario
On 1/16/2023 18:47, Guilherme G. Piccoli wrote: On 16/01/2023 20:00, Alex Deucher wrote: [...] It's not clear to me when this would be used. We only disable it briefly during new asic bring up, after that we never touch it again. No end user on production hardware should ever have to change

RE: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Limonciello, Mario
[Public] > -Original Message- > From: Alex Deucher > Sent: Monday, January 16, 2023 15:54 > To: Limonciello, Mario > Cc: Guilherme G. Piccoli ; amd- > g...@lists.freedesktop.org; Jiang, Sonny ; > ker...@gpiccoli.net; Pan, Xinhui ; dri- > de...@lists.free

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-01-20 Thread Limonciello, Mario
On 1/20/2023 11:46, Guenter Roeck wrote: On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote: This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f. [Why] Changes cause regression on amdgpu mst. E.g. In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload one

RE: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-01-20 Thread Limonciello, Mario
[Public] > -Original Message- > From: Guenter Roeck On Behalf Of Guenter Roeck > Sent: Friday, January 20, 2023 12:18 > To: Limonciello, Mario > Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org; > amd-...@lists.freedesktop.org; sta...@vger.kernel.org; > stanisla

RE: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-01-27 Thread Limonciello, Mario
[Public] > -Original Message- > From: Linux kernel regression tracking (Thorsten Leemhuis) > > Sent: Friday, January 27, 2023 03:15 > To: Greg KH ; Limonciello, Mario > > Cc: dri-devel@lists.freedesktop.org; sta...@vger.kernel.org; > stanislav.lisovs...@int

RE: [PATCH v2 2/2] drm/amdgpu/vcn: Remove redundant indirect SRAM HW model check

2023-01-17 Thread Limonciello, Mario
t; kernel-...@igalia.com; Guilherme G. Piccoli > ; Zhu, James ; Lazar, Lijo > ; Liu, Leo ; Limonciello, Mario > ; Jiang, Sonny > Subject: [PATCH v2 2/2] drm/amdgpu/vcn: Remove redundant indirect SRAM > HW model check > > The HW model validation that guards the indirect SRAM checking

RE: [PATCH v2 2/2] drm/amdgpu/vcn: Remove redundant indirect SRAM HW model check

2023-01-17 Thread Limonciello, Mario
[Public] > -Original Message- > From: Guilherme G. Piccoli > Sent: Tuesday, January 17, 2023 12:14 > To: Limonciello, Mario ; amd- > g...@lists.freedesktop.org; Deucher, Alexander > > Cc: dri-devel@lists.freedesktop.org; Koenig, Christian > ; Pan, Xinhui

RE: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-17 Thread Limonciello, Mario
[Public] > -Original Message- > From: Alex Deucher > Sent: Tuesday, January 17, 2023 09:11 > To: Guilherme G. Piccoli > Cc: Limonciello, Mario ; Liu, Leo > ; amd-...@lists.freedesktop.org; Jiang, Sonny > ; ker...@gpiccoli.net; Pan, Xinhui > ; dri-devel@list

Re: nbio_v7_4: Add pointer check

2022-11-10 Thread Limonciello, Mario
On 11/10/2022 06:28, Denis Arefev wrote: Return value of a function 'amdgpu_ras_find_obj' is dereferenced at nbio_v7_4.c:325 without checking for null This line is too long, you should be wrapping lines at 75 characters. Could you run your patch through checkpatch? Found by Linux

RE: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

2023-02-01 Thread Limonciello, Mario
[AMD Official Use Only - General] > -Original Message- > From: Greg KH > Sent: Sunday, January 29, 2023 07:32 > To: Limonciello, Mario > Cc: Linux regressions mailing list ; dri- > de...@lists.freedesktop.org; sta...@vger.kernel.org; > stanislav.lisovs...@intel.

RE: [PATCH v2] drm/amdgpu/nv: Apply ASPM quirk on Intel ADL + AMD Navi

2023-03-20 Thread Limonciello, Mario
lix ; Zhao, Victor ; > Xiao, Jack ; Quan, Evan ; > Limonciello, Mario ; Lazar, Lijo > ; Chai, Thomas ; Andrey > Grodzovsky ; Somalapuram, Amaranath > ; Zhang, Bokun > ; Liu, Leo ; Gopalakrishnan, > Veerabadhran (Veera) ; Gong, > Richard ; Feng, Kenneth > ; Jian

Re: [PATCH] drm/client: Send hotplug event after registering a client

2023-07-10 Thread Limonciello, Mario
+regressions On 7/10/2023 04:58, Thomas Zimmermann wrote: Hi Am 10.07.23 um 11:52 schrieb Javier Martinez Canillas: Thomas Zimmermann writes: Hello Thomas, Generate a hotplug event after registering a client to allow the client to configure its display. Remove the hotplug calls from the

Re: [PATCH 0/9] Support Wifi RFI interference mitigation feature

2023-05-30 Thread Limonciello, Mario
On 5/30/2023 1:22 AM, Felix Fietkau wrote: On 30.05.23 04:42, 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

Re: [PATCH -next] drm/amdgpu: Remove a lot of unnecessary ternary operators

2023-07-31 Thread Limonciello, Mario
On 7/31/2023 8:26 AM, Ruan Jinjie wrote: Ther are many ternary operators, the true or false judgement of which is unnecessary in C language semantics. s/Ther/There/ Unnecessary; sure. But don't they improve the readability quite a bit? Signed-off-by: Ruan Jinjie ---

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

2023-07-24 Thread Limonciello, Mario
On 7/24/2023 04:22, Andrew Lunn wrote: @@ -1395,6 +1395,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw) debugfs_hw_add(local); rate_control_add_debugfs(local); + ieee80211_check_wbrf_support(local); + rtnl_lock(); wiphy_lock(hw->wiphy); +void

RE: [PATCH] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to acquire gpu_metrics

2023-06-20 Thread Limonciello, Mario
[Public] You've got an A-b from Evan already on this. It looks fine to me too. Reviewed-by: Mario Limonciello > -Original Message- > From: Yang, WenYou > Sent: Sunday, June 11, 2023 12:53 AM > To: Yang, WenYou ; Deucher, Alexander > ; Limonciello, Mario > ; Koenig,

Re: [PATCH V4 3/8] wifi: mac80211: Add support for ACPI WBRF

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 5:22 AM, Johannes Berg wrote: On Wed, 2023-06-21 at 13:45 +0800, Evan Quan wrote: 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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 12:26 PM, Andrew Lunn wrote: I think what you're asking for is another layer of indirection like CONFIG_WBRF in addition to CONFIG_ACPI_WBRF. Producers would call functions like wbrf_supported_producer() where the source file is not guarded behind CONFIG_ACPI_WBRF, but instead by

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
So if we go down this path of CONFIG_WBRF and CONFIG_WBRF_ACPI, another question would be where should the new "wbrf.c" be stored?  The ACPI only version most certainly made sense in drivers/acpi/wbrf.c, but a generic version that only has an ACPI implementation right now not so much. On

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 11:52 AM, Andrew Lunn wrote: On Wed, Jun 21, 2023 at 11:15:00AM -0500, Limonciello, Mario wrote: On 6/21/2023 10:39 AM, Johannes Berg wrote: On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote: On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote: From: Mario Limonciello

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 10:39 AM, Johannes Berg wrote: On Wed, 2023-06-21 at 17:36 +0200, Andrew Lunn wrote: On Wed, Jun 21, 2023 at 01:45:56PM +0800, Evan Quan wrote: From: Mario Limonciello Due to electrical and mechanical constraints in certain platform designs there may be likely interference of

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 11:31 AM, Andrew Lunn wrote: I think there is enough details for this to happen. It's done so that either the AML can natively behave as a consumer or a driver can behave as a consumer. +/** + * APIs needed by drivers/subsystems for contributing frequencies: + * During probe,

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-21 Thread Limonciello, Mario
On 6/21/2023 11:14 AM, Andrew Lunn wrote: Do only ACPI based systems have: interference of relatively high-powered harmonics of the (G-)DDR memory clocks with local radio module frequency bands used by Wifi 6/6e/7." Could Device Tree based systems not experience this problem?

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-22 Thread Limonciello, Mario
On 6/21/2023 8:55 PM, Andrew Lunn wrote: Honestly I'm not sure though we need this complexity right now? I mean, it'd be really easy to replace the calls in mac80211 with some other more generalised calls in the future? You need some really deep platform/hardware level knowledge and

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-23 Thread Limonciello, Mario
On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote: On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote: From: Mario Limonciello 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

RE: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Limonciello, Mario
eedesktop.org; Joonas Lahtinen > ; dri-devel@lists.freedesktop.org; Chai, > Thomas ; Limonciello, Mario > ; Gao, Likun ; David > Airlie ; Ville Syrjala ; Yi > Liu > ; k...@vger.kernel.org; amd-...@lists.freedesktop.org; > Jason Gunthorpe ; Ben Skeggs ; linux- > p..

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

2023-06-19 Thread Limonciello, Mario
On 6/12/2023 2:25 PM, Sui Jingfeng wrote: From: Sui Jingfeng Deal only with the VGA devcie(pdev->class == 0x0300), so replace the pci_get_subsys() function with pci_get_class(). Filter the non-PCI display device(pdev->class != 0x0300) out. There no need to process the non-display PCI device.

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

2023-06-30 Thread Limonciello, Mario
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

Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF mitigations

2023-06-23 Thread Limonciello, Mario
On 6/23/2023 11:28 AM, Rafael J. Wysocki wrote: On Fri, Jun 23, 2023 at 5:57 PM Limonciello, Mario wrote: On 6/23/2023 9:52 AM, Rafael J. Wysocki wrote: On Wed, Jun 21, 2023 at 7:47 AM Evan Quan wrote: From: Mario Limonciello Due to electrical and mechanical constraints in certain

Re: drm/amdgpu: fix an amdgpu_irq_put() issue in gmc_v9_0_hw_fini()

2023-05-03 Thread Limonciello, Mario
On 5/2/2023 11:51 AM, Hamza Mahfooz wrote: As made mention of, in commit 9128e6babf10 ("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini") and commit c094b8923bdd ("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini"). It is meaningless to call amdgpu_irq_put() for

Re: [PATCH] drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2

2024-05-12 Thread Limonciello, Mario
On 5/10/2024 4:24 AM, Jani Nikula wrote: On Fri, 10 May 2024, "Lin, Wayne" wrote: [Public] -Original Message----- From: Limonciello, Mario Sent: Friday, May 10, 2024 3:18 AM To: Linux regressions mailing list ; Wentland, Harry ; Lin, Wayne Cc: ly...@redhat.com; imre.d...

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

2024-05-29 Thread Limonciello, Mario
Also a direct acpi_lid_open() call seems a bit iffy. But I guess if someone needs this to work on non-ACPI system they get to figure out how to abstract it better. acpi_lid_open() does seem to return != 0 when ACPI is not supported, so at least it would err on the side of enabling everything.