| Message ID | 20231017025358.1773598-1-Jun.Ma2@amd.com |
|---|---|
| Headers | show |
| Series | Enable Wifi RFI interference mitigation feature support | expand |
On Tue, 17 Oct 2023, Ma Jun wrote: > From: Evan Quan <quanliangl@hotmail.com> > > Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature. > > Signed-off-by: Evan Quan <quanliangl@hotmail.com> > Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> > Signed-off-by: Ma Jun <Jun.Ma2@amd.com> > -- > v10->v11: > - downgrade the prompt level on message failure(Lijo) > --- > .../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 b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c > index 62f2886ab4df..c5736fb3cf6d 100644 > --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c > @@ -126,6 +126,7 @@ static struct cmn2asic_msg_mapping smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] = > MSG_MAP(AllowGpo, PPSMC_MSG_SetGpoAllow, 0), > MSG_MAP(GetPptLimit, PPSMC_MSG_GetPptLimit, 0), > MSG_MAP(NotifyPowerSource, PPSMC_MSG_NotifyPowerSource, 0), > + MSG_MAP(EnableUCLKShadow, PPSMC_MSG_EnableUCLKShadow, 0), > }; > > static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT] = { > @@ -207,6 +208,7 @@ static struct cmn2asic_mapping smu_v13_0_7_table_map[SMU_TABLE_COUNT] = { > TAB_MAP(ACTIVITY_MONITOR_COEFF), > [SMU_TABLE_COMBO_PPTABLE] = {1, TABLE_COMBO_PPTABLE}, > TAB_MAP(OVERDRIVE), > + TAB_MAP(WIFIBAND), > }; > > static struct cmn2asic_mapping smu_v13_0_7_pwr_src_map[SMU_POWER_SOURCE_COUNT] = { > @@ -503,6 +505,9 @@ static int smu_v13_0_7_tables_init(struct smu_context *smu) > AMDGPU_GEM_DOMAIN_VRAM); > SMU_TABLE_INIT(tables, SMU_TABLE_COMBO_PPTABLE, MP0_MP1_DATA_REGION_SIZE_COMBOPPTABLE, > PAGE_SIZE, AMDGPU_GEM_DOMAIN_VRAM); > + SMU_TABLE_INIT(tables, SMU_TABLE_WIFIBAND, > + sizeof(WifiBandEntryTable_t), PAGE_SIZE, > + AMDGPU_GEM_DOMAIN_VRAM); > > smu_table->metrics_table = kzalloc(sizeof(SmuMetricsExternal_t), GFP_KERNEL); > if (!smu_table->metrics_table) > @@ -2179,6 +2184,57 @@ static int smu_v13_0_7_set_df_cstate(struct smu_context *smu, > NULL); > } > > +static bool smu_v13_0_7_wbrf_support_check(struct smu_context *smu) > +{ > + return smu->smc_fw_version > 0x00524600; > +} > + > +static int smu_v13_0_7_set_wbrf_exclusion_ranges(struct smu_context *smu, > + struct freq_band_range *exclusion_ranges) > +{ > + WifiBandEntryTable_t wifi_bands; > + int valid_entries = 0; > + int ret, i; > + > + memset(&wifi_bands, 0, sizeof(wifi_bands)); > + for (i = 0; i < ARRAY_SIZE(wifi_bands.WifiBandEntry); i++) { > + if (!exclusion_ranges[i].start && > + !exclusion_ranges[i].end) After having seen this construct nth time, I think you should have a static inline function for this check with a proper name. > + break; > + > + /* PMFW expects the inputs to be in Mhz unit */ > + wifi_bands.WifiBandEntry[valid_entries].LowFreq = > + DIV_ROUND_DOWN_ULL(exclusion_ranges[i].start, HZ_IN_MHZ); > + wifi_bands.WifiBandEntry[valid_entries++].HighFreq = > + DIV_ROUND_UP_ULL(exclusion_ranges[i].end, HZ_IN_MHZ); > + } > + wifi_bands.WifiBandEntryNum = valid_entries; > + > + /* > + * Per confirm with PMFW team, WifiBandEntryNum = 0 is a valid setting. > + * Considering the scenarios below: > + * - At first the wifi device adds an exclusion range e.g. (2400,2500) to > + * BIOS and our driver gets notified. We will set WifiBandEntryNum = 1 > + * and pass the WifiBandEntry (2400, 2500) to PMFW. > + * > + * - Later the wifi device removes the wifiband list added above and > + * our driver gets notified again. At this time, driver will set > + * WifiBandEntryNum = 0 and pass an empty WifiBandEntry list to PMFW. > + * - PMFW may still need to do some uclk shadow update(e.g. switching > + * from shadow clock back to primary clock) on receiving this. > + */ > + > + ret = smu_cmn_update_table(smu, > + SMU_TABLE_WIFIBAND, > + 0, > + (void *)(&wifi_bands), > + true); > + if (ret) > + dev_warn(smu->adev->dev, "Failed to set wifiband!"); > + > + return ret; > +} Is this whole function duplicate of the one in the other file? Don't duplicate code like this but create reusable functions properly.
Hi llpo, Thanks for these comments on format issues, I'll fix it in the next version. Regards, Ma Jun On 10/17/2023 5:20 PM, Ilpo Järvinen wrote: > On Tue, 17 Oct 2023, Ma Jun wrote: > >> Add documentation about AMD's Wifi band RFI mitigation (WBRF) mechanism >> explaining the theory and how it is used. >> >> Signed-off-by: Ma Jun <Jun.Ma2@amd.com> >> --- >> Documentation/driver-api/wbrf.rst | 73 +++++++++++++++++++++++++++++++ >> 1 file changed, 73 insertions(+) >> create mode 100644 Documentation/driver-api/wbrf.rst >> >> diff --git a/Documentation/driver-api/wbrf.rst b/Documentation/driver-api/wbrf.rst >> new file mode 100644 >> index 000000000000..8561840263b3 >> --- /dev/null >> +++ b/Documentation/driver-api/wbrf.rst >> @@ -0,0 +1,73 @@ >> +.. SPDX-License-Identifier: GPL-2.0-or-later >> + >> +================================= >> +WBRF - Wifi Band RFI Mitigations >> +================================= >> +Due to electrical and mechanical constraints in certain platform designs > > Add empty line before starting the content of a section. > >> +there may be likely interference of relatively high-powered harmonics of >> +the GPU memory clocks with local radio module frequency bands used by >> +certain Wifi bands. >> + >> +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. >> + >> +When a platform is known to have this issue with any contained devices, >> +the platform designer will advertise the availability of this feature via >> +ACPI devices with a device specific method (_DSM). >> +* Producers with this _DSM will be able to advertise the frequencies in use. >> +* Consumers with this _DSM will be able to register for notifications of >> +frequencies in use. >> + >> +Some general terms >> +================== >> +Producer: such component who can produce high-powered radio frequency >> +Consumer: such component who can adjust its in-use frequency in >> + response to the radio frequencies of other components to >> + mitigate the possible RFI. >> + >> +To make the mechanism function, those producers should notify active use >> +of their particular frequencies so that other consumers can make relative >> +internal adjustments as necessary to avoid this resonance. >> + >> +ACPI interface >> +============== >> +Although initially used by for wifi + dGPU use cases, the ACPI interface >> +can be scaled to any type of device that a platform designer discovers >> +can cause interference. >> + >> +The GUID used for the _DSM is 7B7656CF-DC3D-4C1C-83E9-66E721DE3070. >> + >> +3 functions are available in this _DSM: >> + >> +* 0: discover # of functions available >> +* 1: record RF bands in use >> +* 2: retrieve RF bands in use >> + >> +Driver programming interface >> +============================ >> +.. kernel-doc:: drivers/platform/x86/amd/wbrf.c >> + >> +Sample Usage >> +============= >> +The expected flow for the producers: >> +1) During probe, call `acpi_amd_wbrf_supported_producer` to check if WBRF >> +can be enabled for the device. >> +2) On using some frequency band, call `acpi_amd_wbrf_add_remove` with 'add' >> +param to get other consumers properly notified. >> +3) Or on stopping using some frequency band, call >> +`acpi_amd_wbrf_add_remove` with 'remove' param to get other consumers notified. >> + >> +The expected flow for the consumers: >> +1) During probe, call `acpi_amd_wbrf_supported_consumer` to check if WBRF >> +can be enabled for the device. >> +2) Call `amd_wbrf_register_notifier` to register for notification >> +of frequency band change(add or remove) from other producers. >> +3) Call the `amd_wbrf_retrieve_freq_band` intentionally to retrieve >> +current active frequency bands considering some producers may broadcast >> +such information before the consumer is up. >> +4) On receiving a notification for frequency band change, run >> +`amd_wbrf_retrieve_freq_band` again to retrieve the latest >> +active frequency bands. >> +5) During driver cleanup, call `amd_wbrf_unregister_notifier` to >> +unregister the notifier. > > Align these so that only the numbers start from first column. I think the > proper markup for numbered lists is 1. not 1). > >
ping... Any other comments? Regards, Ma Jun On 10/17/2023 10:53 AM, Ma Jun 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 we introuduced WBRF(Wifi Band RFI mitigation Feature). > 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 Linux 6.5.0. With some brief introductions > as below: > Patch1: Document about WBRF > Patch2: Core functionality setup for WBRF feature support > Patch3 - 4: Bring WBRF support to wifi subsystem. > Patch5 - 9: Bring WBRF support to AMD graphics driver. > > Evan Quan (7): > cfg80211: expose nl80211_chan_width_to_mhz for wide sharing > wifi: mac80211: Add support for WBRF features > 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 > > Ma Jun (2): > Documentation/driver-api: Add document about WBRF mechanism > platform/x86/amd: Add support for AMD ACPI based Wifi band RFI > mitigation feature > > Documentation/driver-api/wbrf.rst | 71 +++ > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 + > drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 214 +++++++++ > drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 33 ++ > .../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 | 60 +++ > .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++ > drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + > drivers/platform/x86/amd/Kconfig | 15 + > drivers/platform/x86/amd/Makefile | 1 + > drivers/platform/x86/amd/wbrf.c | 422 ++++++++++++++++++ > include/linux/acpi_amd_wbrf.h | 101 +++++ > include/linux/ieee80211.h | 1 + > include/net/cfg80211.h | 8 + > net/mac80211/Makefile | 2 + > net/mac80211/chan.c | 9 + > net/mac80211/ieee80211_i.h | 9 + > net/mac80211/main.c | 2 + > net/mac80211/wbrf.c | 105 +++++ > net/wireless/chan.c | 3 +- > 27 files changed, 1180 insertions(+), 6 deletions(-) > create mode 100644 Documentation/driver-api/wbrf.rst > create mode 100644 drivers/platform/x86/amd/wbrf.c > create mode 100644 include/linux/acpi_amd_wbrf.h > create mode 100644 net/mac80211/wbrf.c >
Hi, On 10/19/23 08:17, Ma, Jun wrote: > ping... > Any other comments? Patches 1/9 and 2/9 look reasonable, once the questions about use of the _DSM vs directly calling the WBRF ACPI method are resolved I can merge patches 1/9 and 2/9 and create an immutable feature branch based on 6.7-rc1 + these 2 patches. I'll then also send a pull-request to the wifi /resp amdgpu maintainers from this branch. I see no acks / reviews from the wifi folks yet, so once that immutable feature branch is ready the first thing to do is try to get the wifi folks to review + merge WBRF support. Note I plan to not actually merge the feature branch into for-next until the wifi folks are happy with the code. This way if changes are necessary I can do a v2 feature branch and the wifi folks can merge that instead. Regards, Hans > On 10/17/2023 10:53 AM, Ma Jun 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 we introuduced WBRF(Wifi Band RFI mitigation Feature). >> 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 Linux 6.5.0. With some brief introductions >> as below: >> Patch1: Document about WBRF >> Patch2: Core functionality setup for WBRF feature support >> Patch3 - 4: Bring WBRF support to wifi subsystem. >> Patch5 - 9: Bring WBRF support to AMD graphics driver. >> >> Evan Quan (7): >> cfg80211: expose nl80211_chan_width_to_mhz for wide sharing >> wifi: mac80211: Add support for WBRF features >> 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 >> >> Ma Jun (2): >> Documentation/driver-api: Add document about WBRF mechanism >> platform/x86/amd: Add support for AMD ACPI based Wifi band RFI >> mitigation feature >> >> Documentation/driver-api/wbrf.rst | 71 +++ >> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + >> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 + >> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 214 +++++++++ >> drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 33 ++ >> .../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 | 60 +++ >> .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++ >> drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + >> drivers/platform/x86/amd/Kconfig | 15 + >> drivers/platform/x86/amd/Makefile | 1 + >> drivers/platform/x86/amd/wbrf.c | 422 ++++++++++++++++++ >> include/linux/acpi_amd_wbrf.h | 101 +++++ >> include/linux/ieee80211.h | 1 + >> include/net/cfg80211.h | 8 + >> net/mac80211/Makefile | 2 + >> net/mac80211/chan.c | 9 + >> net/mac80211/ieee80211_i.h | 9 + >> net/mac80211/main.c | 2 + >> net/mac80211/wbrf.c | 105 +++++ >> net/wireless/chan.c | 3 +- >> 27 files changed, 1180 insertions(+), 6 deletions(-) >> create mode 100644 Documentation/driver-api/wbrf.rst >> create mode 100644 drivers/platform/x86/amd/wbrf.c >> create mode 100644 include/linux/acpi_amd_wbrf.h >> create mode 100644 net/mac80211/wbrf.c >> >
Hi Hans, Thanks for review and your suggestion. I'll check and fix the _DSM calling issue in the next version. Regards, Ma Jun On 11/20/2023 6:54 PM, Hans de Goede wrote: > Hi, > > On 10/19/23 08:17, Ma, Jun wrote: >> ping... >> Any other comments? > > Patches 1/9 and 2/9 look reasonable, once the questions about > use of the _DSM vs directly calling the WBRF ACPI method are > resolved I can merge patches 1/9 and 2/9 and create an immutable > feature branch based on 6.7-rc1 + these 2 patches. > > I'll then also send a pull-request to the wifi /resp amdgpu > maintainers from this branch. > > I see no acks / reviews from the wifi folks yet, > so once that immutable feature branch is ready the first > thing to do is try to get the wifi folks to review + merge WBRF > support. > > Note I plan to not actually merge the feature branch > into for-next until the wifi folks are happy with the code. > > This way if changes are necessary I can do a v2 feature branch > and the wifi folks can merge that instead. > > Regards, > > Hans > > > > >> On 10/17/2023 10:53 AM, Ma Jun 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 we introuduced WBRF(Wifi Band RFI mitigation Feature). >>> 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 Linux 6.5.0. With some brief introductions >>> as below: >>> Patch1: Document about WBRF >>> Patch2: Core functionality setup for WBRF feature support >>> Patch3 - 4: Bring WBRF support to wifi subsystem. >>> Patch5 - 9: Bring WBRF support to AMD graphics driver. >>> >>> Evan Quan (7): >>> cfg80211: expose nl80211_chan_width_to_mhz for wide sharing >>> wifi: mac80211: Add support for WBRF features >>> 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 >>> >>> Ma Jun (2): >>> Documentation/driver-api: Add document about WBRF mechanism >>> platform/x86/amd: Add support for AMD ACPI based Wifi band RFI >>> mitigation feature >>> >>> Documentation/driver-api/wbrf.rst | 71 +++ >>> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + >>> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 + >>> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 214 +++++++++ >>> drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 33 ++ >>> .../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 | 60 +++ >>> .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++ >>> drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + >>> drivers/platform/x86/amd/Kconfig | 15 + >>> drivers/platform/x86/amd/Makefile | 1 + >>> drivers/platform/x86/amd/wbrf.c | 422 ++++++++++++++++++ >>> include/linux/acpi_amd_wbrf.h | 101 +++++ >>> include/linux/ieee80211.h | 1 + >>> include/net/cfg80211.h | 8 + >>> net/mac80211/Makefile | 2 + >>> net/mac80211/chan.c | 9 + >>> net/mac80211/ieee80211_i.h | 9 + >>> net/mac80211/main.c | 2 + >>> net/mac80211/wbrf.c | 105 +++++ >>> net/wireless/chan.c | 3 +- >>> 27 files changed, 1180 insertions(+), 6 deletions(-) >>> create mode 100644 Documentation/driver-api/wbrf.rst >>> create mode 100644 drivers/platform/x86/amd/wbrf.c >>> create mode 100644 include/linux/acpi_amd_wbrf.h >>> create mode 100644 net/mac80211/wbrf.c >>> >> >
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 we introuduced WBRF(Wifi Band RFI mitigation Feature). 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 Linux 6.5.0. With some brief introductions as below: Patch1: Document about WBRF Patch2: Core functionality setup for WBRF feature support Patch3 - 4: Bring WBRF support to wifi subsystem. Patch5 - 9: Bring WBRF support to AMD graphics driver. Evan Quan (7): cfg80211: expose nl80211_chan_width_to_mhz for wide sharing wifi: mac80211: Add support for WBRF features 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 Ma Jun (2): Documentation/driver-api: Add document about WBRF mechanism platform/x86/amd: Add support for AMD ACPI based Wifi band RFI mitigation feature Documentation/driver-api/wbrf.rst | 71 +++ drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 17 + drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 214 +++++++++ drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 33 ++ .../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 | 60 +++ .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++ drivers/gpu/drm/amd/pm/swsmu/smu_internal.h | 3 + drivers/platform/x86/amd/Kconfig | 15 + drivers/platform/x86/amd/Makefile | 1 + drivers/platform/x86/amd/wbrf.c | 422 ++++++++++++++++++ include/linux/acpi_amd_wbrf.h | 101 +++++ include/linux/ieee80211.h | 1 + include/net/cfg80211.h | 8 + net/mac80211/Makefile | 2 + net/mac80211/chan.c | 9 + net/mac80211/ieee80211_i.h | 9 + net/mac80211/main.c | 2 + net/mac80211/wbrf.c | 105 +++++ net/wireless/chan.c | 3 +- 27 files changed, 1180 insertions(+), 6 deletions(-) create mode 100644 Documentation/driver-api/wbrf.rst create mode 100644 drivers/platform/x86/amd/wbrf.c create mode 100644 include/linux/acpi_amd_wbrf.h create mode 100644 net/mac80211/wbrf.c