mbox series

[0/9] Support Wifi RFI interference mitigation feature

Message ID 20230530024227.2139632-1-evan.quan@amd.com
Headers
Series Support Wifi RFI interference mitigation feature |

Message

Evan Quan May 30, 2023, 2:42 a.m. UTC 
  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 the frequencies in use and
consumers can use this information to avoid using these frequencies for
sensitive features.

The whole patch set is based on 6.4-rc3. With some brief introductions as below:
Patch1:     Core ACPI interfaces needed to support WBRF feature.
Patch2 - 4: Enable WBRF support for some Mediatek and Qualcomm wifi drivers.
Patch5 - 9: Enable WBRF support for AMD graphics driver.

Anson Tsao (1):
  wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF

Evan Quan (6):
  wifi: ath12k: Add support to the Qualcomm ath12k for ACPI WBRF
  drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature
  drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
  drm/amd/pm: add flood detection for wbrf events
  drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
  drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7

Mario Limonciello (2):
  drivers/acpi: Add support for Wifi band RF mitigations
  mt76: Add support to the Mediatek MT7921 for ACPI WBRF

 drivers/acpi/Kconfig                          |   7 +
 drivers/acpi/Makefile                         |   2 +
 drivers/acpi/acpi_wbrf.c                      | 343 ++++++++++++++++++
 drivers/gpu/drm/amd/amdgpu/amdgpu.h           |  26 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c      |  63 ++++
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c       |  19 +
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c     | 204 +++++++++++
 drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  31 ++
 .../inc/pmfw_if/smu13_driver_if_v13_0_0.h     |  14 +-
 .../inc/pmfw_if/smu13_driver_if_v13_0_7.h     |  14 +-
 .../pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h  |   3 +-
 .../pm/swsmu/inc/pmfw_if/smu_v13_0_7_ppsmc.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/drm/amd/pm/swsmu/smu13/smu_v13_0.c    |   9 +
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  |  62 ++++
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  |  61 ++++
 drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
 drivers/net/wireless/ath/Makefile             |   1 +
 drivers/net/wireless/ath/acpi_wbrf.c          |  45 +++
 drivers/net/wireless/ath/ath.h                |  15 +
 drivers/net/wireless/ath/ath11k/core.c        |  23 ++
 drivers/net/wireless/ath/ath11k/core.h        |  14 +
 drivers/net/wireless/ath/ath11k/mac.c         |   4 +
 drivers/net/wireless/ath/ath11k/pci.c         |   3 +
 drivers/net/wireless/ath/ath12k/core.c        |  21 ++
 drivers/net/wireless/ath/ath12k/core.h        |  14 +
 drivers/net/wireless/ath/ath12k/mac.c         |   4 +
 drivers/net/wireless/ath/ath12k/pci.c         |   3 +
 drivers/net/wireless/mediatek/mt76/Makefile   |   1 +
 .../net/wireless/mediatek/mt76/acpi_wbrf.c    |  36 ++
 drivers/net/wireless/mediatek/mt76/mt76.h     |  19 +
 .../net/wireless/mediatek/mt76/mt7921/init.c  |   2 +
 .../net/wireless/mediatek/mt76/mt7921/main.c  |   3 +
 include/linux/wbrf.h                          |  70 ++++
 35 files changed, 1143 insertions(+), 5 deletions(-)
 create mode 100644 drivers/acpi/acpi_wbrf.c
 create mode 100644 drivers/net/wireless/ath/acpi_wbrf.c
 create mode 100644 drivers/net/wireless/mediatek/mt76/acpi_wbrf.c
 create mode 100644 include/linux/wbrf.h

Comments

Felix Fietkau May 30, 2023, 6:22 a.m. UTC | #1 
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 used by Wifi 6/6e/7. To mitigate
> possible RFI interference producers can advertise the frequencies in use and
> consumers can use this information to avoid using these frequencies for
> sensitive features.
> 
> The whole patch set is based on 6.4-rc3. With some brief introductions as below:
> Patch1:     Core ACPI interfaces needed to support WBRF feature.
> Patch2 - 4: Enable WBRF support for some Mediatek and Qualcomm wifi drivers.
> Patch5 - 9: Enable WBRF support for AMD graphics driver.
> 
> Anson Tsao (1):
>    wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF
> 
> Evan Quan (6):
>    wifi: ath12k: Add support to the Qualcomm ath12k for ACPI WBRF
>    drm/amd/pm: update driver_if and ppsmc headers for coming wbrf feature
>    drm/amd/pm: setup the framework to support Wifi RFI mitigation feature
>    drm/amd/pm: add flood detection for wbrf events
>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
> 
> Mario Limonciello (2):
>    drivers/acpi: Add support for Wifi band RF mitigations
>    mt76: Add support to the Mediatek MT7921 for ACPI WBRF
Wouldn't it make more sense to put this in mac80211 or cfg80211 instead 
of duplicating the logic in different drivers?

- Felix
Mario Limonciello May 30, 2023, 3:34 p.m. UTC | #2 
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 used by Wifi 6/6e/7. 
>> To mitigate
>> possible RFI interference producers can advertise the frequencies in 
>> use and
>> consumers can use this information to avoid using these frequencies for
>> sensitive features.
>>
>> The whole patch set is based on 6.4-rc3. With some brief 
>> introductions as below:
>> Patch1:     Core ACPI interfaces needed to support WBRF feature.
>> Patch2 - 4: Enable WBRF support for some Mediatek and Qualcomm wifi 
>> drivers.
>> Patch5 - 9: Enable WBRF support for AMD graphics driver.
>>
>> Anson Tsao (1):
>>    wifi: ath11k: Add support to the Qualcomm ath11k for ACPI WBRF
>>
>> Evan Quan (6):
>>    wifi: ath12k: Add support to the Qualcomm ath12k for ACPI WBRF
>>    drm/amd/pm: update driver_if and ppsmc headers for coming wbrf 
>> feature
>>    drm/amd/pm: setup the framework to support Wifi RFI mitigation 
>> feature
>>    drm/amd/pm: add flood detection for wbrf events
>>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0
>>    drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.7
>>
>> Mario Limonciello (2):
>>    drivers/acpi: Add support for Wifi band RF mitigations
>>    mt76: Add support to the Mediatek MT7921 for ACPI WBRF
> Wouldn't it make more sense to put this in mac80211 or cfg80211 
> instead of duplicating the logic in different drivers?
>
> - Felix
>
I think it's generally a sensible proposal, but there are a few things 
that need to be agreed upon to find the right places
for everything.

1) The actual notifying, would it make sense to put it directly into 
these functions?

ieee80211_add_chanctx / ieee80211_del_chanctx

2) "Where" should the WBRF support detection need to happen?

wbrf_supported_producer needs to have an argument of the ACPI companion 
for the device.
What level *should* the ACPI device be found?
Should that still be individual drivers calling a mac80211 helper 
function to indicate they're opting in?
Or should there there be some CONFIG_ACPI_WBRF gated helper as part of a 
driver registration?