RE: [PATCH] drm/amdgpu: fix retry loop test

[Quan, Evan]

[AMD Official Use Only - General]

Yeah, nice catch. But personally I would prefer to change the check as "if 
(retry <= 0)".
Either way, the patch is reviewed-by: Evan Quan 

Evan
> -Original Message-
> From: Dan Carpenter 
> Sent: Wednesday, September 6, 2023 6:55 PM
> To: Quan, Evan ; Wang, Yang(Kevin)
> 
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Lazar, Lijo
> ; Kamal, Asad ; Zhang,
> Hawking ; Limonciello, Mario
> ; amd-gfx@lists.freedesktop.org; kernel-
> janit...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: fix retry loop test
>
> This loop will exit with "retry" set to -1 if it fails but the code
> checks for if "retry" is zero.  Fix this by changing post-op to a
> pre-op.  --retry vs retry--.
>
> Fixes: e01eeffc3f86 ("drm/amd/pm: avoid driver getting empty metrics table
> for the first time")
> Signed-off-by: Dan Carpenter 
> ---
> Obviously this only loop 99 times now instead of a hundred but that's
> fine, this is an approximation.
>
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> index ff58ee14a68f..20163a9b2a66 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c
> @@ -336,7 +336,7 @@ static int smu_v13_0_6_setup_driver_pptable(struct
> smu_context *smu)
>
>   /* Store one-time values in driver PPTable */
>   if (!pptable->Init) {
> - while (retry--) {
> + while (--retry) {
>   ret = smu_v13_0_6_get_metrics_table(smu, NULL,
> true);
>   if (ret)
>   return ret;
> --
> 2.39.2

RE: [V3 0/7] A new set of Linux OD interfaces

[Quan, Evan]

[AMD Official Use Only - General]

Actually, with my original design, there indeed came with an 'r' option support.
But I found that brings some confusion. Since per current 'r' option design, it 
will
reset all attributes back to original states. Thus I dropped it.

If to support 'r' option per attribute, some redesigns to current logics will 
be needed
to support both legacy and the new OD interfaces. That will need some extra 
efforts.
Maybe we can put that on our TODO list?

Evan
> -Original Message-
> From: Alex Deucher 
> Sent: Friday, September 1, 2023 1:26 AM
> To: Quan, Evan 
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> 
> Subject: Re: [V3 0/7] A new set of Linux OD interfaces
>
> For consistency with the other OD interface, we'd probably want an "r"
> option to reset each attribute to the default state again.
>
> Alex
>
> On Wed, Aug 30, 2023 at 9:33 AM Alex Deucher 
> wrote:
> >
> > Series is:
> > Reviewed-by: Alex Deucher 
> >
> > On Wed, Aug 30, 2023 at 2:35 AM Evan Quan 
> wrote:
> > >
> > > The existing OD interface `pp_od_clk_voltage` is unable to meet the
> > > growing demands for more OD functionalities. Since the buf used
> > > within it comes with size limit as one page. With more OD
> > > functionalities added, we will hit that limit soon.
> > >
> > > To better meet the growing demainds, a new set of OD interfaces are
> designed.
> > > With this new design, there will be multiple interfaces exposed with
> > > each representing a single OD functionality. And all those
> > > interfaces will be arranged in a tree liked hierarchy as below.
> > > Meanwhile all functionalities for the same component will be arranged
> under the same directory.
> > >
> > > gpu_od/
> > > ├── fan_ctrl
> > > │   ├── acoustic_limit_rpm_threshold
> > > │   ├── acoustic_target_rpm_threshold
> > > │   ├── fan_curve
> > > │   ├── fan_minimum_pwm
> > > │   ├── fan_target_temperature
> > >
> > > Evan Quan (7):
> > >   drm/amd/pm: introduce a new set of OD interfaces
> > >   drm/amdgpu: revise the device initialization sequences
> > >   drm/amd/pm: add fan temperature/pwm curve OD setting support for
> SMU13
> > >   drm/amd/pm: add fan acoustic limit OD setting support for SMU13
> > >   drm/amd/pm: add fan acoustic target OD setting support for SMU13
> > >   drm/amd/pm: add fan target temperature OD setting support for SMU13
> > >   drm/amd/pm: add fan minimum pwm OD setting support for SMU13
> > >
> > >  Documentation/gpu/amdgpu/thermal.rst  |  30 +
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  39 +-
> > >  .../gpu/drm/amd/include/kgd_pp_interface.h|  12 +-
> > >  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 730
> +-
> > >  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |  14 +
> > >  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |  10 +
> > >  drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |   5 +
> > >  .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 298 ++-
> > > .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  | 298 ++-
> > >  9 files changed, 1411 insertions(+), 25 deletions(-)
> > >
> > > --
> > > 2.34.1
> > >

RE: [PATCH v3] drm/amd/pm: only poweron/off vcn/jpeg when they are valid.

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Zhang, Yifan 
> Sent: Thursday, August 31, 2023 2:27 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Ma, Li ; Zhang,
> Yifan 
> Subject: [PATCH v3] drm/amd/pm: only poweron/off vcn/jpeg when they are
> valid.
>
> If vcn is disabled in kernel parameters, don't touch vcn,
> otherwise it may cause vcn hang.
>
> v2: delete unnecessary logs
> v3: move "is_vcn_enabled" check to smu_dpm_setvcn/jpeg_enable (Evan)
>
> Signed-off-by: Yifan Zhang 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 24
> +++
>  1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index f005a90c35af..e3e1f69643ce 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -215,6 +215,21 @@ static int smu_set_gfx_imu_enable(struct
> smu_context *smu)
>   return smu_set_gfx_power_up_by_imu(smu);
>  }
>
> +static bool is_vcn_enabled(struct amdgpu_device *adev)
> +{
> + int i;
> +
> + for (i = 0; i < adev->num_ip_blocks; i++) {
> + if ((adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_VCN ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_JPEG) &&
> + !adev->ip_blocks[i].status.valid)
> +
There seems an extra empty line here. With this dropped, the patch is 
reviewed-by: Evan Quan 

Evan
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static int smu_dpm_set_vcn_enable(struct smu_context *smu,
> bool enable)
>  {
> @@ -222,6 +237,12 @@ static int smu_dpm_set_vcn_enable(struct
> smu_context *smu,
>   struct smu_power_gate *power_gate = &smu_power->power_gate;
>   int ret = 0;
>
> + /*
> +  * don't poweron vcn/jpeg when they are skipped.
> +  */
> + if (!is_vcn_enabled(smu->adev))
> + return 0;
> +
>   if (!smu->ppt_funcs->dpm_set_vcn_enable)
>   return 0;
>
> @@ -242,6 +263,9 @@ static int smu_dpm_set_jpeg_enable(struct
> smu_context *smu,
>   struct smu_power_gate *power_gate = &smu_power->power_gate;
>   int ret = 0;
>
> + if (!is_vcn_enabled(smu->adev))
> + return 0;
> +
>   if (!smu->ppt_funcs->dpm_set_jpeg_enable)
>   return 0;
>
> --
> 2.37.3

RE: [PATCH] drm/amd/pm: only poweron/off vcn/jpeg when they are valid.

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Zhang, Yifan 
> Sent: Thursday, August 31, 2023 2:10 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Ma, Li ; Zhang,
> Yifan 
> Subject: [PATCH] drm/amd/pm: only poweron/off vcn/jpeg when they are
> valid.
>
> If vcn is disabled in kernel parameters, don't touch vcn,
> otherwise it may cause vcn hang.
>
> Signed-off-by: Yifan Zhang 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 31
> ---
>  1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index f005a90c35af..f5e7ce011cab 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -1454,6 +1454,21 @@ static int smu_start_smc_engine(struct
> smu_context *smu)
>   return ret;
>  }
>
> +static bool is_vcn_enabled(struct amdgpu_device *adev)
> +{
> + int i;
> +
> + for (i = 0; i < adev->num_ip_blocks; i++) {
> + if ((adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_VCN ||
> + adev->ip_blocks[i].version->type ==
> AMD_IP_BLOCK_TYPE_JPEG) &&
> + !adev->ip_blocks[i].status.valid)
> +
> + return false;
> + }
> +
> + return true;
> +}
> +
>  static int smu_hw_init(void *handle)
>  {
>   int ret;
> @@ -1475,8 +1490,14 @@ static int smu_hw_init(void *handle)
>   ret = smu_set_gfx_imu_enable(smu);
>   if (ret)
>   return ret;
> - smu_dpm_set_vcn_enable(smu, true);
> - smu_dpm_set_jpeg_enable(smu, true);
> + /*
> +  * don't poweron vcn/jpeg when they are skipped.
> +  */
> + if (is_vcn_enabled(adev)) {
> + dev_info(adev->dev, "yep, vcn are valid\n");
> + smu_dpm_set_vcn_enable(smu, true);
> + smu_dpm_set_jpeg_enable(smu, true);
> + }
Better to move the "is_vcn_enabled" check into `smu_dpm_set_vcn/jpeg_enable`. 
That will make code more tidy.
Also, the "dev_info" here is obviously not needed.

Evan
>   smu_set_gfx_cgpg(smu, true);
>   }
>
> @@ -1651,8 +1672,10 @@ static int smu_hw_fini(void *handle)
>   if (amdgpu_sriov_vf(adev) && !amdgpu_sriov_is_pp_one_vf(adev))
>   return 0;
>
> - smu_dpm_set_vcn_enable(smu, false);
> - smu_dpm_set_jpeg_enable(smu, false);
> + if (is_vcn_enabled(adev)) {
> + smu_dpm_set_vcn_enable(smu, false);
> + smu_dpm_set_jpeg_enable(smu, false);
> + }
>
>   adev->vcn.cur_state = AMD_PG_STATE_GATE;
>   adev->jpeg.cur_state = AMD_PG_STATE_GATE;
> --
> 2.37.3

RE: [V10 1/8] ACPI: Add support for AMD ACPI based Wifi band RFI mitigation feature

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Simon Horman 
> Sent: Sunday, August 27, 2023 11:43 PM
> To: Quan, Evan 
> Cc: l...@kernel.org; johan...@sipsolutions.net; da...@davemloft.net;
> eduma...@google.com; k...@kernel.org; pab...@redhat.com; Deucher,
> Alexander ; raf...@kernel.org; Lazar, Lijo
> ; Limonciello, Mario ;
> linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [V10 1/8] ACPI: Add support for AMD ACPI based Wifi band RFI
> mitigation feature
>
> On Fri, Aug 25, 2023 at 04:38:39PM +0800, 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 introduced a mechanism that devices can use
> > to notify active use of particular frequencies so that other devices
> > can make relative internal adjustments as necessary to avoid this resonance.
> >
> > Signed-off-by: Evan Quan 
>
> ...
>
> > diff --git a/drivers/acpi/amd_wbrf.c b/drivers/acpi/amd_wbrf.c
>
> ...
>
> > +/**
> > + * acpi_amd_wbrf_add_exclusion - broadcast the frequency band the
> device
> > + *   is using
> > + *
> > + * @dev: device pointer
> > + * @in: input structure containing the frequency band the device is
> > +using
> > + *
> > + * Broadcast to other consumers the frequency band the device starts
> > + * to use. Underneath the surface the information is cached into an
> > + * internal buffer first. Then a notification is sent to all those
> > + * registered consumers. So then they can retrieve that buffer to
> > + * know the latest active frequency bands. The benifit with such
> > +design
>
> nit: ./checkpatch.pl --codespell suggests benifit -> benefit.
Thanks, will fix that.

Evan
>
> > + * is for those consumers which have not been registered yet, they
> > +can
> > + * still have a chance to retrieve such information later.
> > + */
> > +int acpi_amd_wbrf_add_exclusion(struct device *dev,
> > +   struct wbrf_ranges_in_out *in)
> > +{
> > +   struct acpi_device *adev = ACPI_COMPANION(dev);
> > +   int ret;
> > +
> > +   if (!adev)
> > +   return -ENODEV;
> > +
> > +   ret = wbrf_record(adev, WBRF_RECORD_ADD, in);
> > +   if (ret)
> > +   return ret;
> > +
> > +   blocking_notifier_call_chain(&wbrf_chain_head,
> > +WBRF_CHANGED,
> > +NULL);
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(acpi_amd_wbrf_add_exclusion);
>
> ...

RE: [V10 7/8] drm/amd/pm: enable Wifi RFI mitigation feature support for SMU13.0.0

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Lazar, Lijo 
> Sent: Friday, August 25, 2023 10:13 PM
> To: Quan, Evan ; l...@kernel.org;
> johan...@sipsolutions.net; da...@davemloft.net; eduma...@google.com;
> k...@kernel.org; pab...@redhat.com; Deucher, Alexander
> ; raf...@kernel.org; Limonciello, Mario
> 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [V10 7/8] drm/amd/pm: enable Wifi RFI mitigation feature
> support for SMU13.0.0
>
>
>
> On 8/25/2023 2:08 PM, Evan Quan wrote:
> > 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 +
> >   .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c|  9 +++
> >   .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 60
> +++
> >   5 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> > b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> > index 60d595344c45..a081e6bb27c4 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> > @@ -325,6 +325,7 @@ enum smu_table_id
> > SMU_TABLE_PACE,
> > SMU_TABLE_ECCINFO,
> > SMU_TABLE_COMBO_PPTABLE,
> > +   SMU_TABLE_WIFIBAND,
> > SMU_TABLE_COUNT,
> >   };
> >
> > @@ -1501,6 +1502,8 @@ enum smu_baco_seq {
> >  __dst_size);  \
> >   })
> >
> > +#define HZ_IN_MHZ  100U
> > +
> >   #if !defined(SWSMU_CODE_LAYER_L2)
> && !defined(SWSMU_CODE_LAYER_L3)
> && !defined(SWSMU_CODE_LAYER_L4)
> >   int smu_get_power_limit(void *handle,
> > uint32_t *limit,
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> > b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> > index 297b70b9388f..5bbb60289a79 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> > @@ -245,7 +245,8 @@
> > __SMU_DUMMY_MAP(AllowGpo),  \
> > __SMU_DUMMY_MAP(Mode2Reset),\
> > __SMU_DUMMY_MAP(RequestI2cTransaction), \
> > -   __SMU_DUMMY_MAP(GetMetricsTable),
> > +   __SMU_DUMMY_MAP(GetMetricsTable), \
> > +   __SMU_DUMMY_MAP(EnableUCLKShadow),
> >
> >   #undef __SMU_DUMMY_MAP
> >   #define __SMU_DUMMY_MAP(type) SMU_MSG_##type
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> > b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> > index 355c156d871a..dd70b56aa71e 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h
> > @@ -299,5 +299,8 @@ int smu_v13_0_update_pcie_parameters(struct
> smu_context *smu,
> >  uint32_t pcie_gen_cap,
> >  uint32_t pcie_width_cap);
> >
> > +int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
> > +bool enablement);
> > +
> >   #endif
> >   #endif
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> > index 9b62b45ebb7f..6a5cb582aa92 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> > @@ -2472,3 +2472,12 @@ int smu_v13_0_update_pcie_parameters(struct
> > smu_context *smu,
> >
> > return 0;
> >   }
> > +
> > +int smu_v13_0_enable_uclk_shadow(struct smu_context *smu,
> > +bool enablement)
> > +{
> > +   return smu_cmn_send_smc_msg_with_param(smu,
> > +  SMU_MSG_EnableUCLKShadow,
> > +  enablement,
> > +  NULL);
> > +}
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> > index 3d188616ba24..fd3ac18653ed 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> > @@ -

RE: [V10 5/8] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Lazar, Lijo 
> Sent: Friday, August 25, 2023 10:09 PM
> To: Quan, Evan ; l...@kernel.org;
> johan...@sipsolutions.net; da...@davemloft.net; eduma...@google.com;
> k...@kernel.org; pab...@redhat.com; Deucher, Alexander
> ; raf...@kernel.org; Limonciello, Mario
> 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [V10 5/8] drm/amd/pm: setup the framework to support Wifi
> RFI mitigation feature
>
>
>
> On 8/25/2023 2:08 PM, Evan Quan wrote:
> > 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 Limonciello 
> > --
> > v1->v2:
> >- update the prompt for feature support(Lijo)
> > v8->v9:
> >- update parameter document for smu_wbrf_event_handler(Simon)
> > v9->v10:
> >   - correct the logics for wbrf range sorting(Lijo)
> > ---
> >   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 | 195
> ++
> >   drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  23 +++
> >   drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
> >   5 files changed, 240 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index a3b86b86dc47..2bfc9111ab00 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -247,6 +247,8 @@ extern int amdgpu_sg_display;
> >
> >   extern int amdgpu_user_partt_mode;
> >
> > +extern int amdgpu_wbrf;
> > +
> >   #define AMDGPU_VM_MAX_NUM_CTX 4096
> >   #define AMDGPU_SG_THRESHOLD   (256*1024*1024)
> >   #define AMDGPU_WAIT_IDLE_TIMEOUT_IN_MS3000
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 0593ef8fe0a6..1c574bd3b60d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -195,6 +195,7 @@ int amdgpu_use_xgmi_p2p = 1;
> >   int amdgpu_vcnfw_log;
> >   int amdgpu_sg_display = -1; /* auto */
> >   int amdgpu_user_partt_mode =
> AMDGPU_AUTO_COMPUTE_PARTITION_MODE;
> > +int amdgpu_wbrf = -1;
> >
> >   static void amdgpu_drv_delayed_reset_work_handler(struct work_struct
> > *work);
> >
> > @@ -981,6 +982,22 @@ module_param_named(user_partt_mode,
> amdgpu_user_partt_mode, uint, 0444);
> >   module_param(enforce_isolation, bool, 0444);
> >   MODULE_PARM_DESC(enforce_isolation, "enforce process isolation
> > between graphics and compute . enforce_isolation = on");
> >
> > +/**
> > + * DOC: wbrf (int)
> > + * Enable Wifi RFI interference mitigation feature.
> > + * Due to electrical and mechanical constraints 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 the
> > +possible RFI interference,
> > + * with this feature enabled, PMFW will use either “shadowed P-State”
> > +or “P-State” based
> > + * on active list of frequencies in-use (to be avoided) as part of
> > +initial setting or
> > + * P-state transition. However, there may be potential performance
> > +impact with this
> > + * feature enabled.
> > + * (0 = disabled, 1 = enabled, -1 = auto (default setting, will be
> > +enabled if supported))  */ MODULE_PARM_DESC(wbrf,
> > +   "Enable Wifi RFI interference mitigation (0 = disabled, 1 = enabled,
> > +-1 = auto(default)"); module_param_named(wbrf, amdgpu_wbrf, int,
> > +0444);
> > +
> >   /* These devices are not supported by amdgpu.
> >* They are supported by the mach64, r128, radeon drivers
> >*/
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > index ce41a8309582..bdfd234d1558 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.

RE: [V9 6/9] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Lazar, Lijo 
> Sent: Friday, August 18, 2023 5:12 PM
> To: Quan, Evan ; gre...@linuxfoundation.org;
> raf...@kernel.org; l...@kernel.org; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Deucher, Alexander ;
> and...@lunn.ch; rdun...@infradead.org; quic_jjohn...@quicinc.com;
> ho...@kernel.org
> Cc: linux-...@vger.kernel.org; net...@vger.kernel.org; linux-
> wirel...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; linux-a...@vger.kernel.org; Limonciello, Mario
> 
> Subject: Re: [V9 6/9] drm/amd/pm: setup the framework to support Wifi RFI
> mitigation feature
>
>
>
> On 8/18/2023 8:56 AM, Evan Quan wrote:
> > 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 Limonciello 
> > --
> > v1->v2:
> >- update the prompt for feature support(Lijo)
> > v8->v9:
> >- update parameter document for smu_wbrf_event_handler(Simon)
> > ---
> >   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 | 194
> ++
> >   drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  23 +++
> >   drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
> >   5 files changed, 239 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index a3b86b86dc47..2bfc9111ab00 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -247,6 +247,8 @@ extern int amdgpu_sg_display;
> >
> >   extern int amdgpu_user_partt_mode;
> >
> > +extern int amdgpu_wbrf;
> > +
> >   #define AMDGPU_VM_MAX_NUM_CTX 4096
> >   #define AMDGPU_SG_THRESHOLD   (256*1024*1024)
> >   #define AMDGPU_WAIT_IDLE_TIMEOUT_IN_MS3000
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 0593ef8fe0a6..1c574bd3b60d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -195,6 +195,7 @@ int amdgpu_use_xgmi_p2p = 1;
> >   int amdgpu_vcnfw_log;
> >   int amdgpu_sg_display = -1; /* auto */
> >   int amdgpu_user_partt_mode =
> AMDGPU_AUTO_COMPUTE_PARTITION_MODE;
> > +int amdgpu_wbrf = -1;
> >
> >   static void amdgpu_drv_delayed_reset_work_handler(struct work_struct
> > *work);
> >
> > @@ -981,6 +982,22 @@ module_param_named(user_partt_mode,
> amdgpu_user_partt_mode, uint, 0444);
> >   module_param(enforce_isolation, bool, 0444);
> >   MODULE_PARM_DESC(enforce_isolation, "enforce process isolation
> > between graphics and compute . enforce_isolation = on");
> >
> > +/**
> > + * DOC: wbrf (int)
> > + * Enable Wifi RFI interference mitigation feature.
> > + * Due to electrical and mechanical constraints 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 the
> > +possible RFI interference,
> > + * with this feature enabled, PMFW will use either “shadowed P-State”
> > +or “P-State” based
> > + * on active list of frequencies in-use (to be avoided) as part of
> > +initial setting or
> > + * P-state transition. However, there may be potential performance
> > +impact with this
> > + * feature enabled.
> > + * (0 = disabled, 1 = enabled, -1 = auto (default setting, will be
> > +enabled if supported))  */ MODULE_PARM_DESC(wbrf,
> > +   "Enable Wifi RFI interference mitigation (0 = disabled, 1 = enabled,
> > +-1 = auto(default)"); module_param_named(wbrf, amdgpu_wbrf, int,
> > +0444);
> > +
> >   /* These devices are not supported by amdgpu.
> >* They are supported by the mach64, r128, radeon drivers
> >*/
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > index ce41a8309582..704442ce1da3 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> > +++ b/drivers/gpu/drm/am

RE: [V9 4/9] wifi: mac80211: Add support for WBRF features

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Johannes Berg 
> Sent: Monday, August 21, 2023 5:44 PM
> To: Quan, Evan ; gre...@linuxfoundation.org;
> raf...@kernel.org; l...@kernel.org; da...@davemloft.net;
> eduma...@google.com; k...@kernel.org; pab...@redhat.com; Deucher,
> Alexander ; and...@lunn.ch;
> rdun...@infradead.org; quic_jjohn...@quicinc.com; ho...@kernel.org
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org; Limonciello, Mario
> 
> Subject: Re: [V9 4/9] wifi: mac80211: Add support for WBRF features
>
> On Fri, 2023-08-18 at 11:26 +0800, Evan Quan wrote:
> > To support the WBRF mechanism, Wifi adapters utilized in the system
> > must register the frequencies in use(or unregister those frequencies
> > no longer
> > used) via the dedicated calls. So that, other drivers responding to
> > the frequencies can take proper actions to mitigate possible interference.
> >
> > Co-developed-by: Mario Limonciello 
> > Signed-off-by: Mario Limonciello 
> > Co-developed-by: Evan Quan 
> > Signed-off-by: Evan Quan 
>
> From WiFi POV, this looks _almost_ fine to me.
>
> > +static void wbrf_get_ranges_from_chandef(struct cfg80211_chan_def
> *chandef,
> > +struct wbrf_ranges_in *ranges_in) {
> > +   u64 start_freq1, end_freq1;
> > +   u64 start_freq2, end_freq2;
> > +   int bandwidth;
> > +
> > +   bandwidth = nl80211_chan_width_to_mhz(chandef->width);
> > +
> > +   get_chan_freq_boundary(chandef->center_freq1,
> > +  bandwidth,
> > +  &start_freq1,
> > +  &end_freq1);
> > +
> > +   ranges_in->band_list[0].start = start_freq1;
> > +   ranges_in->band_list[0].end = end_freq1;
> > +
> > +   if (chandef->width == NL80211_CHAN_WIDTH_80P80) {
> > +   get_chan_freq_boundary(chandef->center_freq2,
> > +  bandwidth,
> > +  &start_freq2,
> > +  &end_freq2);
> > +
> > +   ranges_in->band_list[1].start = start_freq2;
> > +   ranges_in->band_list[1].end = end_freq2;
> > +   }
> > +}
>
> This has to setup ranges_in->num_of_ranges, no?
Yes, better to have that. I add this in V10.
> (Also no real good reason for num_of_ranges to be a u64, btw, since it can
> only go up to 11)
Mainly for data structure alignment. Since other members come with u64.
So, to make the data structure naturally aligned, 'num_of_ranges' also comes 
with u64.

Evan
>
> With that fixed, you can add
>
> Reviewed-by: Johannes Berg 
>
> johannes

RE: [PATCH] drm/amd/pm: workaround for the wrong ac power detection on smu 13.0.0

[Quan, Evan]

[AMD Official Use Only - General]

As discussed offline, better to document something like "this is a temporary 
solution and will be dropped in the future".
Either way, the patch is reviewed-by: Evan Quan 

Evan
> -Original Message-
> From: Kenneth Feng 
> Sent: Friday, August 25, 2023 11:19 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Feng, Kenneth
> 
> Subject: [PATCH] drm/amd/pm: workaround for the wrong ac power
> detection on smu 13.0.0
>
> workaround for the wrong ac power detection on smu 13.0.0
>
> Signed-off-by: Kenneth Feng 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c   | 3 +--
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 1 -
>  2 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> index 0232adb95df3..fd1798fd716e 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c
> @@ -1021,8 +1021,7 @@ static int
> smu_v13_0_process_pending_interrupt(struct smu_context *smu)
>  {
>   int ret = 0;
>
> - if (smu->dc_controlled_by_gpio &&
> - smu_cmn_feature_is_enabled(smu, SMU_FEATURE_ACDC_BIT))
> + if (smu_cmn_feature_is_enabled(smu, SMU_FEATURE_ACDC_BIT))
>   ret = smu_v13_0_allow_ih_interrupt(smu);
>
>   return ret;
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index 3903a47669e4..128468355375 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -2664,7 +2664,6 @@ static const struct pptable_funcs
> smu_v13_0_0_ppt_funcs = {
>   .enable_mgpu_fan_boost = smu_v13_0_0_enable_mgpu_fan_boost,
>   .get_power_limit = smu_v13_0_0_get_power_limit,
>   .set_power_limit = smu_v13_0_set_power_limit,
> - .set_power_source = smu_v13_0_set_power_source,
>   .get_power_profile_mode = smu_v13_0_0_get_power_profile_mode,
>   .set_power_profile_mode = smu_v13_0_0_set_power_profile_mode,
>   .run_btc = smu_v13_0_run_btc,
> --
> 2.34.1

RE: [V2 3/8] drm/amd/pm: add fan mode OD setting support for SMU13

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Alex Deucher 
> Sent: Thursday, August 24, 2023 10:51 PM
> To: Quan, Evan 
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> 
> Subject: Re: [V2 3/8] drm/amd/pm: add fan mode OD setting support for
> SMU13
>
> On Wed, Aug 23, 2023 at 10:28 PM Quan, Evan 
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Alex Deucher 
> > > Sent: Wednesday, August 23, 2023 9:29 PM
> > > To: Quan, Evan 
> > > Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> > > 
> > > Subject: Re: [V2 3/8] drm/amd/pm: add fan mode OD setting support
> > > for
> > > SMU13
> > >
> > > On Wed, Aug 23, 2023 at 2:45 AM Evan Quan 
> > > wrote:
> > > >
> > > > Add SMU13 fan mode OD setting support.
> > > >
> > > > Signed-off-by: Evan Quan 
> > > > --
> > > > v1->v2:
> > > >   - add missing kerneldoc for the new interface(Alex)
> > > > ---
> > > >  Documentation/gpu/amdgpu/thermal.rst  |   6 +
> > > >  .../gpu/drm/amd/include/kgd_pp_interface.h|   4 +-
> > > >  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 200
> > > +-
> > > >  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |   4 +
> > > >  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |   2 +
> > > >  drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |   1 +
> > > >  .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  |  35 ++-
> > > > .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  |  35 ++-
> > > >  8 files changed, 279 insertions(+), 8 deletions(-)
> > > >
> > > > diff --git a/Documentation/gpu/amdgpu/thermal.rst
> > > > b/Documentation/gpu/amdgpu/thermal.rst
> > > > index 5e27e4eb3959..8757ec7f0136 100644
> > > > --- a/Documentation/gpu/amdgpu/thermal.rst
> > > > +++ b/Documentation/gpu/amdgpu/thermal.rst
> > > > @@ -64,6 +64,12 @@ gpu_metrics
> > > >  .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > :doc: gpu_metrics
> > > >
> > > > +fan_mode
> > > > +
> > > > +
> > > > +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > +   :doc: fan_mode
> > > > +
> > > >  GFXOFF
> > > >  ==
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > > > b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > > > index 84c5224d994c..020c9ce1f735 100644
> > > > --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > > > +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > > > @@ -113,6 +113,7 @@ enum pp_clock_type {
> > > > OD_RANGE,
> > > > OD_VDDGFX_OFFSET,
> > > > OD_CCLK,
> > > > +   OD_FAN_MODE,
> > > >  };
> > > >
> > > >  enum amd_pp_sensors {
> > > > @@ -186,7 +187,8 @@ enum PP_OD_DPM_TABLE_COMMAND {
> > > > PP_OD_EDIT_VDDC_CURVE,
> > > > PP_OD_RESTORE_DEFAULT_TABLE,
> > > > PP_OD_COMMIT_DPM_TABLE,
> > > > -   PP_OD_EDIT_VDDGFX_OFFSET
> > > > +   PP_OD_EDIT_VDDGFX_OFFSET,
> > > > +   PP_OD_EDIT_FAN_MODE,
> > > >  };
> > > >
> > > >  struct pp_states_info {
> > > > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > index beb3303fc832..d53d60903fe9 100644
> > > > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > > > @@ -3383,7 +3383,205 @@ static const struct attribute_group
> > > *hwmon_groups[] = {
> > > > NULL
> > > >  };
> > > >
> > > > -static struct od_feature_set amdgpu_od_set;
> > > > +static int amdgpu_retrieve_od_settings(struct amdgpu_device *adev,
> > > > +  enum pp_clock_type od_type,
> > > > +  char *buf) {
> > > > +   int size = 0;
> > > > +   int ret;
> > > > +
> > > > +   if (amdgpu_in_reset(adev))
> > > > +   return -EPERM;
> > > > +   if (adev->in_suspend && !adev->in_runpm)
> > > > + 

RE: [V2 3/8] drm/amd/pm: add fan mode OD setting support for SMU13

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Alex Deucher 
> Sent: Wednesday, August 23, 2023 9:29 PM
> To: Quan, Evan 
> Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> 
> Subject: Re: [V2 3/8] drm/amd/pm: add fan mode OD setting support for
> SMU13
>
> On Wed, Aug 23, 2023 at 2:45 AM Evan Quan 
> wrote:
> >
> > Add SMU13 fan mode OD setting support.
> >
> > Signed-off-by: Evan Quan 
> > --
> > v1->v2:
> >   - add missing kerneldoc for the new interface(Alex)
> > ---
> >  Documentation/gpu/amdgpu/thermal.rst  |   6 +
> >  .../gpu/drm/amd/include/kgd_pp_interface.h|   4 +-
> >  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 200
> +-
> >  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |   4 +
> >  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |   2 +
> >  drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |   1 +
> >  .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  |  35 ++-
> > .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  |  35 ++-
> >  8 files changed, 279 insertions(+), 8 deletions(-)
> >
> > diff --git a/Documentation/gpu/amdgpu/thermal.rst
> > b/Documentation/gpu/amdgpu/thermal.rst
> > index 5e27e4eb3959..8757ec7f0136 100644
> > --- a/Documentation/gpu/amdgpu/thermal.rst
> > +++ b/Documentation/gpu/amdgpu/thermal.rst
> > @@ -64,6 +64,12 @@ gpu_metrics
> >  .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > :doc: gpu_metrics
> >
> > +fan_mode
> > +
> > +
> > +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > +   :doc: fan_mode
> > +
> >  GFXOFF
> >  ==
> >
> > diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > index 84c5224d994c..020c9ce1f735 100644
> > --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > @@ -113,6 +113,7 @@ enum pp_clock_type {
> > OD_RANGE,
> > OD_VDDGFX_OFFSET,
> > OD_CCLK,
> > +   OD_FAN_MODE,
> >  };
> >
> >  enum amd_pp_sensors {
> > @@ -186,7 +187,8 @@ enum PP_OD_DPM_TABLE_COMMAND {
> > PP_OD_EDIT_VDDC_CURVE,
> > PP_OD_RESTORE_DEFAULT_TABLE,
> > PP_OD_COMMIT_DPM_TABLE,
> > -   PP_OD_EDIT_VDDGFX_OFFSET
> > +   PP_OD_EDIT_VDDGFX_OFFSET,
> > +   PP_OD_EDIT_FAN_MODE,
> >  };
> >
> >  struct pp_states_info {
> > diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > index beb3303fc832..d53d60903fe9 100644
> > --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> > @@ -3383,7 +3383,205 @@ static const struct attribute_group
> *hwmon_groups[] = {
> > NULL
> >  };
> >
> > -static struct od_feature_set amdgpu_od_set;
> > +static int amdgpu_retrieve_od_settings(struct amdgpu_device *adev,
> > +  enum pp_clock_type od_type,
> > +  char *buf) {
> > +   int size = 0;
> > +   int ret;
> > +
> > +   if (amdgpu_in_reset(adev))
> > +   return -EPERM;
> > +   if (adev->in_suspend && !adev->in_runpm)
> > +   return -EPERM;
> > +
> > +   ret = pm_runtime_get_sync(adev->dev);
> > +   if (ret < 0) {
> > +   pm_runtime_put_autosuspend(adev->dev);
> > +   return ret;
> > +   }
> > +
> > +   size = amdgpu_dpm_print_clock_levels(adev, od_type, buf);
> > +   if (size == 0)
> > +   size = sysfs_emit(buf, "\n");
> > +
> > +   pm_runtime_mark_last_busy(adev->dev);
> > +   pm_runtime_put_autosuspend(adev->dev);
> > +
> > +   return size;
> > +}
> > +
> > +static int parse_input_od_command_lines(const char *buf,
> > +   size_t count,
> > +   u32 *type,
> > +   long *params,
> > +   uint32_t *num_of_params) {
> > +   const char delimiter[3] = {' ', '\n', '\0'};
> > +   uint32_t parameter_size = 0;
> > +   char buf_cpy[128] = {0};
> > +   char *tmp_str, *sub_str;
> > +   int ret;
> > +
> > +   if (count > sizeof(buf_cpy) - 1)
> > +   return -EINVAL;
>

RE: [PATCH 0/8] A new set of Linux OD interfaces

[Quan, Evan]

[AMD Official Use Only - General]

Ping..

> -Original Message-
> From: Quan, Evan 
> Sent: Tuesday, August 15, 2023 4:42 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: [PATCH 0/8] A new set of Linux OD interfaces
>
> The existing OD interface `pp_od_clk_voltage` is unable to meet the growing
> demands for more OD functionalities. Since the buf used within it comes with
> size limit as one page. With more OD functionalities added, we will hit that
> limit soon.
>
> To better meet the growing demainds, a new set of OD interfaces are designed.
> With this new design, there will be multiple interfaces exposed with each
> representing a single OD functionality. And all those interfaces will be 
> arranged
> in a tree liked hierarchy as below. Meanwhile all functionalities for the same
> component will be arranged under the same directory.
>
> gpu_od/
> ├── fan_ctrl
> ├── acoustic_limit_rpm_threshold
> ├── acoustic_target_rpm_threshold
> ├── fan_curve
> ├── fan_minimum_pwm
> ├── fan_mode
> ├── fan_target_temperature
> ...
> ...(more to be added)
>
>
> Evan Quan (8):
>   drm/amd/pm: introduce a new set of OD interfaces
>   drm/amdgpu: revise the device initialization sequences
>   drm/amd/pm: add fan mode OD setting support for SMU13
>   drm/amd/pm: add fan temperature/pwm curve OD setting support for
> SMU13
>   drm/amd/pm: add fan acoustic limit OD setting support for SMU13
>   drm/amd/pm: add fan acoustic target OD setting support for SMU13
>   drm/amd/pm: add fan target temperature OD setting support for SMU13
>   drm/amd/pm: add fan minimum pwm OD setting support for SMU13
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  39 +-
>  .../gpu/drm/amd/include/kgd_pp_interface.h|  14 +-
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 676 +-
>  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |  16 +
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |  12 +
>  drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |   6 +
>  .../drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c  | 316 +++-
>   .../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c  | 316 +++-
>  8 files changed, 1370 insertions(+), 25 deletions(-)
>
> --
> 2.34.1

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

[Quan, Evan]

[AMD Official Use Only - General]

Hi Andrew,

I sent out a new V8 series last week.
A kernel parameter `wbrf` was introduced there to decide the policy.
Please help to check whether that makes sense to you.
Please share your insights there.

BR,
Evan
> -Original Message-
> From: Andrew Lunn 
> Sent: Wednesday, July 26, 2023 4:10 AM
> To: Limonciello, Mario 
> Cc: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; mdaen...@redhat.com;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo
> ; jim.cro...@gmail.com; bellosili...@gmail.com;
> andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de;
> linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF
> 
> > This comes back to the point that was mentioned by Johannes - you need
> > to have deep design understanding of the hardware to know whether or
> > not you will have producers that a consumer need to react to.
> 
> Yes, this is the policy is keep referring to. I would expect that there is 
> something
> somewhere in ACPI which says for this machine, the policy is Yes/No.
> 
> It could well be that AMD based machine has a different ACPI extension to
> indicate this policy to what Intel machine has. As far as i understand it, you
> have not submitted this yet for formal approval, this is all vendor specific, 
> so
> Intel could do it completely differently. Hence i would expect a generic API 
> to
> tell the core what the policy is, and your glue code can call into ACPI to 
> find out
> that information, and then tell the core.
> 
> > If all producers indicate their frequency and all consumers react to
> > it you may have activated mitigations that are unnecessary. The
> > hardware designer may have added extra shielding or done the layout
> > such that they're not needed.
> 
> And the policy will indicate No, nothing needs to be done. The core can then
> tell produces and consumes not to bother telling the core anything.
> 
> > So I don't think we're ever going to be in a situation that the
> > generic implementation should be turned on by default.  It's a "developer
> knob".
> 
> Wrong. You should have a generic core, which your AMD CPU DDR device
> plugs into. The Intel CPU DDR device can plug into, the nvidea GPU can plug
> into, your Radeon GPU can plug into, the intel ARC can plug into, the generic
> WiFi core plugs into, etc.
> 
> > If needed these can then be enabled using the AMD ACPI interface, a DT
> > one if one is developed or maybe even an allow-list of SMBIOS strings.
> 
> Notice i've not mentioned DT for a while. I just want a generic core, which
> AMD, Intel, nvidea, Ampare, Graviton, Qualcomm, Marvell, ..., etc can use. We
> should be solving this problem once, for everybody, not adding a solution for
> just one vendor.
> 
>   Andrew

RE: [PATCH V8 3/9] cfg80211: expose nl80211_chan_width_to_mhz for wide sharing

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Jeff Johnson 
> Sent: Thursday, August 10, 2023 10:06 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; and...@lunn.ch
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V8 3/9] cfg80211: expose nl80211_chan_width_to_mhz
> for wide sharing
> 
> On 8/10/2023 12:37 AM, Evan Quan wrote:
> > 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
> > 7c7d03aa9d06..f50508e295db 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
> >   cfg80211_chandef_compatible(const struct cfg80211_chan_def
> *chandef1,
> > const struct cfg80211_chan_def *chandef2);
> >
> > +/**
> > + * nl80211_chan_width_to_mhz - get the channel width in Mhz
> > + * @chan_width: the channel width from &enum nl80211_chan_width
> > + * Return: channel width in Mhz if the chan_width from &enum
> > +nl80211_chan_width
> > + * is valid. -1 otherwise.
> 
> SI nit: s/Mhz/MHz/ in both places
Thanks, will update them accordingly.

Evan
> 
> > + */
> > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width
> chan_width);
> > +
> >   /**
> >* cfg80211_chandef_valid - check if a channel definition is valid
> >* @chandef: the channel definition to check diff --git
> > a/net/wireless/chan.c b/net/wireless/chan.c index
> > 0b7e81db383d..227db04eac42 100644
> > --- a/net/wireless/chan.c
> > +++ b/net/wireless/chan.c
> > @@ -141,7 +141,7 @@ static bool cfg80211_edmg_chandef_valid(const
> struct cfg80211_chan_def *chandef)
> > return true;
> >   }
> >
> > -static int nl80211_chan_width_to_mhz(enum nl80211_chan_width
> > chan_width)
> > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width chan_width)
> >   {
> > int mhz;
> >
> > @@ -190,6 +190,7 @@ static int nl80211_chan_width_to_mhz(enum
> nl80211_chan_width chan_width)
> > }
> > return mhz;
> >   }
> > +EXPORT_SYMBOL(nl80211_chan_width_to_mhz);
> >
> >   static int cfg80211_chandef_get_width(const struct cfg80211_chan_def
> *c)
> >   {

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

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Randy Dunlap 
> Sent: Thursday, August 10, 2023 11:41 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; and...@lunn.ch
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V8 1/9] drivers core: Add support for Wifi band RF
> mitigations
> 
> 
> 
> On 8/10/23 00:37, Evan Quan wrote:
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt
> > b/Documentation/admin-guide/kernel-parameters.txt
> > index a1457995fd41..21f73a0bbd0b 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -7152,3 +7152,12 @@
> > xmon commands.
> > off xmon is disabled.
> >
> > +   wbrf=   [KNL]
> > +   Format: { on | auto | off }
> > +   Controls if WBRF features should be enabled or
> disabled
> > +   forcely. Default is auto.
> 
> "forcely" is not a word. "forcedly" is a word, but it's not used very much 
> AFAIK.
> I would probably write "Controls if WBRF features should be forced on or off."
Yeah, that sounds better. Will update this as suggested.

Evan
> 
> > +   on  Force enable the WBRF features.
> > +   autoUp to the system to do proper checks to
> > +   determine the WBRF features should be
> enabled
> > +   or not.
> > +   off Force disable the WBRF features.
> 
> --
> ~Randy

RE: [PATCH V8 6/9] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Simon Horman 
> Sent: Friday, August 11, 2023 5:35 PM
> To: Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; and...@lunn.ch; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V8 6/9] drm/amd/pm: setup the framework to support
> Wifi RFI mitigation feature
> 
> On Thu, Aug 10, 2023 at 03:38:00PM +0800, Evan Quan wrote:
> > 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 Limonciello 
> 
> ...
> 
> > +/**
> > + * smu_wbrf_event_handler - handle notify events
> > + *
> > + * @nb: notifier block
> > + * @action: event type
> > + * @data: event data
> 
> Hi Evan,
> 
> a minor nit from my side: although it is documented here,
> smu_wbrf_event_handler has no @data parameter, while
> it does have an undocumented _arg parameter.
Thanks for pointing this out. I will fix this.

Evan
> 
> > + *
> > + * Calls relevant amdgpu function in response to wbrf event
> > + * notification from kernel.
> > + */
> > +static int smu_wbrf_event_handler(struct notifier_block *nb,
> > + unsigned long action, void *_arg)
> > +{
> > +   struct smu_context *smu = container_of(nb, struct smu_context,
> > +  wbrf_notifier);
> > +
> > +   switch (action) {
> > +   case WBRF_CHANGED:
> > +   smu_wbrf_handle_exclusion_ranges(smu);
> > +   break;
> > +   default:
> > +   return NOTIFY_DONE;
> > +   };
> > +
> > +   return NOTIFY_OK;
> > +}
> 
> ...

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

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Simon Horman 
> Sent: Friday, August 11, 2023 5:38 PM
> To: Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; and...@lunn.ch; linux-
> ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V8 2/9] drivers core: add ACPI based WBRF mechanism
> introduced by AMD
> 
> On Thu, Aug 10, 2023 at 03:37:56PM +0800, Evan Quan wrote:
> > 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/fall-back the generic WBRF solution for diagnosing potential
> > interference issues.
> >
> > And for the platform which does not equip with the necessary AMD ACPI
> > implementations but with CONFIG_WBRF_AMD_ACPI built as 'y', it will
> > fall back to generic WBRF solution if the `wbrf` is set as "on".
> >
> > Co-developed-by: Mario Limonciello 
> > Signed-off-by: Mario Limonciello 
> > Co-developed-by: Evan Quan 
> > Signed-off-by: Evan Quan 
> 
> ...
> 
> > diff --git a/drivers/acpi/amd_wbrf.c b/drivers/acpi/amd_wbrf.c
> 
> ...
> 
> > +static bool check_acpi_wbrf(acpi_handle handle, u64 rev, u64 funcs)
> > +{
> > +   int i;
> > +   u64 mask = 0;
> > +   union acpi_object *obj;
> > +
> > +   if (funcs == 0)
> > +   return false;
> > +
> > +   obj = acpi_evaluate_wbrf(handle, rev, 0);
> > +   if (!obj)
> > +   return false;
> > +
> > +   if (obj->type != ACPI_TYPE_BUFFER)
> > +   return false;
> > +
> > +   /*
> > +* Bit vector providing supported functions information.
> > +* Each bit marks support for one specific function of the WBRF
> method.
> > +*/
> > +   for (i = 0; i < obj->buffer.length && i < 8; i++)
> > +   mask |= (((u64)obj->buffer.pointer[i]) << (i * 8));
> > +
> > +   ACPI_FREE(obj);
> > +
> > +   if ((mask & BIT(WBRF_ENABLED)) &&
> > +(mask & funcs) == funcs)
> 
> Hi Evan,
> 
> a minor nit from my side: the indentation of the line above seems odd.
Thanks. Will update this.

Evan
> 
>   if ((mask & BIT(WBRF_ENABLED)) &&
>   (mask & funcs) == funcs)
> 
> > +   return true;
> > +
> > +   return false;
> > +}
> 
> ...

RE: [PATCH] fix throttle_status for other than MP0 11.0.7

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: Umio Yasuno 
> Sent: Tuesday, August 8, 2023 2:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> ; Limonciello, Mario 
> Subject: [PATCH] fix throttle_status for other than MP0 11.0.7
>
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2720
> Signed-off-by: Umio Yasuno 
> ---
>  .../drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index 85d53597e..548d25cf3 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -578,7 +578,9 @@ static int sienna_cichlid_tables_init(struct
> smu_context *smu)
>   return -ENOMEM;
>  }
>
> -static uint32_t sienna_cichlid_get_throttler_status_locked(struct
> smu_context *smu)
> +static uint32_t sienna_cichlid_get_throttler_status_locked(struct
> smu_context *smu,
> +bool
> use_metrics_v3,
> +bool
> use_metrics_v2)
>  {
>   struct smu_table_context *smu_table= &smu->smu_table;
>   SmuMetricsExternal_t *metrics_ext =
> @@ -586,13 +588,11 @@ static uint32_t
> sienna_cichlid_get_throttler_status_locked(struct smu_context *s
>   uint32_t throttler_status = 0;
>   int i;
>
> - if ((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0, 7))
> &&
> -  (smu->smc_fw_version >= 0x3A4900)) {
> + if (use_metrics_v3) {
>   for (i = 0; i < THROTTLER_COUNT; i++)
>   throttler_status |=
>   (metrics_ext-
> >SmuMetrics_V3.ThrottlingPercentage[i] ? 1U << i : 0);
> - } else if ((smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11,
> 0, 7)) &&
> -  (smu->smc_fw_version >= 0x3A4300)) {
> + } else if (use_metrics_v2) {
>   for (i = 0; i < THROTTLER_COUNT; i++)
>   throttler_status |=
>   (metrics_ext-
> >SmuMetrics_V2.ThrottlingPercentage[i] ? 1U << i : 0);
> @@ -854,7 +854,7 @@ static int sienna_cichlid_get_smu_metrics_data(struct
> smu_context *smu,
>   metrics->TemperatureVrSoc) *
> SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
>   break;
>   case METRICS_THROTTLER_STATUS:
> - *value = sienna_cichlid_get_throttler_status_locked(smu);
> + *value = sienna_cichlid_get_throttler_status_locked(smu,
> use_metrics_v3, use_metrics_v2);
>   break;
>   case METRICS_CURR_FANSPEED:
>   *value = use_metrics_v3 ? metrics_v3->CurrFanSpeed :
> @@ -4056,7 +4056,7 @@ static ssize_t
> sienna_cichlid_get_gpu_metrics(struct smu_context *smu,
>   gpu_metrics->current_dclk1 = use_metrics_v3 ? metrics_v3-
> >CurrClock[PPCLK_DCLK_1] :
>   use_metrics_v2 ? metrics_v2->CurrClock[PPCLK_DCLK_1] :
> metrics->CurrClock[PPCLK_DCLK_1];
>
> - gpu_metrics->throttle_status =
> sienna_cichlid_get_throttler_status_locked(smu);
> + gpu_metrics->throttle_status =
> sienna_cichlid_get_throttler_status_locked(smu, use_metrics_v3,
> use_metrics_v2);
>   gpu_metrics->indep_throttle_status =
>   smu_cmn_get_indep_throttler_status(gpu_metrics-
> >throttle_status,
>
> sienna_cichlid_throttler_map);
> --
> 2.40.1
>

RE: [PATCH -next] drm/amd/pm: Remove many unnecessary NULL values

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: Ruan Jinjie 
> Sent: Tuesday, August 1, 2023 8:55 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; mrip...@kernel.org;
> tzimmerm...@suse.de; d...@mailo.com; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Cc: ruanjin...@huawei.com
> Subject: [PATCH -next] drm/amd/pm: Remove many unnecessary NULL values
>
> Ther are many pointers assigned first, which need not to be initialized, so
> remove the NULL assignment.
>
> Signed-off-by: Ruan Jinjie 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c  | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c| 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c   | 2 +-
>  5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
> index 182118e3fd5f..5794b64507bf 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/processpptables.c
> @@ -1237,7 +1237,7 @@ static int get_vce_clock_voltage_limit_table(struct
> pp_hwmgr *hwmgr,
>   const VCEClockInfoArray*array)
>  {
>   unsigned long i;
> - struct phm_vce_clock_voltage_dependency_table *vce_table = NULL;
> + struct phm_vce_clock_voltage_dependency_table *vce_table;
>
>   vce_table = kzalloc(struct_size(vce_table, entries, table->numEntries),
>   GFP_KERNEL);
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
> index 4bc8db1be738..9e4228232f02 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c
> @@ -2732,7 +2732,7 @@ static bool ci_is_dpm_running(struct pp_hwmgr
> *hwmgr)
>
>  static int ci_smu_init(struct pp_hwmgr *hwmgr)
>  {
> - struct ci_smumgr *ci_priv = NULL;
> + struct ci_smumgr *ci_priv;
>
>   ci_priv = kzalloc(sizeof(struct ci_smumgr), GFP_KERNEL);
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
> index 02c094a06605..5e43ad2b2956 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/fiji_smumgr.c
> @@ -332,7 +332,7 @@ static bool fiji_is_hw_avfs_present(struct pp_hwmgr
> *hwmgr)
>
>  static int fiji_smu_init(struct pp_hwmgr *hwmgr)
>  {
> - struct fiji_smumgr *fiji_priv = NULL;
> + struct fiji_smumgr *fiji_priv;
>
>   fiji_priv = kzalloc(sizeof(struct fiji_smumgr), GFP_KERNEL);
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
> index 060fc140c574..97d9802fe673 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c
> @@ -259,7 +259,7 @@ static int iceland_start_smu(struct pp_hwmgr
> *hwmgr)
>
>  static int iceland_smu_init(struct pp_hwmgr *hwmgr)
>  {
> - struct iceland_smumgr *iceland_priv = NULL;
> + struct iceland_smumgr *iceland_priv;
>
>   iceland_priv = kzalloc(sizeof(struct iceland_smumgr), GFP_KERNEL);
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
> index acbe41174d7e..6fe6e6abb5d8 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c
> @@ -226,7 +226,7 @@ static int tonga_start_smu(struct pp_hwmgr
> *hwmgr)
>
>  static int tonga_smu_init(struct pp_hwmgr *hwmgr)
>  {
> - struct tonga_smumgr *tonga_priv = NULL;
> + struct tonga_smumgr *tonga_priv;
>
>   tonga_priv = kzalloc(sizeof(struct tonga_smumgr), GFP_KERNEL);
>   if (tonga_priv == NULL)
> --
> 2.34.1

RE: [PATCH] drm/amdgpu: Clean up errors in vega20_baco.c

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Ran
> Sun
> Sent: Tuesday, August 1, 2023 4:03 PM
> To: Deucher, Alexander ; airl...@gmail.com;
> dan...@ffwll.ch
> Cc: Ran Sun ; dri-de...@lists.freedesktop.org;
> amd-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: Clean up errors in vega20_baco.c
>
> Fix the following errors reported by checkpatch:
>
> ERROR: that open brace { should be on the previous line
> ERROR: space required before the open parenthesis '('
>
> Signed-off-by: Ran Sun 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_baco.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_baco.c
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_baco.c
> index 8d99c7a5abf8..994c0d374bfa 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_baco.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_baco.c
> @@ -31,8 +31,7 @@
>
>  #include "amdgpu_ras.h"
>
> -static const struct soc15_baco_cmd_entry clean_baco_tbl[] = -{
> +static const struct soc15_baco_cmd_entry clean_baco_tbl[] = {
>   {CMD_WRITE, SOC15_REG_ENTRY(NBIF, 0, mmBIOS_SCRATCH_6), 0,
> 0, 0, 0},
>   {CMD_WRITE, SOC15_REG_ENTRY(NBIF, 0, mmBIOS_SCRATCH_7), 0,
> 0, 0, 0},  }; @@ -90,11 +89,11 @@ int vega20_baco_set_state(struct
> pp_hwmgr *hwmgr, enum BACO_STATE state)
>   data |= 0x8000;
>   WREG32_SOC15(THM, 0, mmTHM_BACO_CNTL,
> data);
>
> - if(smum_send_msg_to_smc_with_parameter(hwmgr,
> + if
> (smum_send_msg_to_smc_with_parameter(hwmgr,
>   PPSMC_MSG_EnterBaco, 0, NULL))
>   return -EINVAL;
>   } else {
> - if(smum_send_msg_to_smc_with_parameter(hwmgr,
> + if
> (smum_send_msg_to_smc_with_parameter(hwmgr,
>   PPSMC_MSG_EnterBaco, 1, NULL))
>   return -EINVAL;
>   }
> --
> 2.17.1

RE: [PATCH] drm/amd/pm: Clean up errors in vega20_hwmgr.h

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Ran
> Sun
> Sent: Tuesday, August 1, 2023 10:39 AM
> To: Deucher, Alexander ; airl...@gmail.com;
> dan...@ffwll.ch
> Cc: Ran Sun ; dri-de...@lists.freedesktop.org;
> amd-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amd/pm: Clean up errors in vega20_hwmgr.h
>
> Fix the following errors reported by checkpatch:
>
> ERROR: open brace '{' following enum go on the same line
>
> Signed-off-by: Ran Sun 
> ---
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
> index 075c0094da9c..1ba9b5fe2a5d 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_hwmgr.h
> @@ -385,8 +385,7 @@ struct vega20_odn_data {
>   struct vega20_odn_temp_tableodn_temp_table;
>  };
>
> -enum OD8_FEATURE_ID
> -{
> +enum OD8_FEATURE_ID {
>   OD8_GFXCLK_LIMITS   = 1 << 0,
>   OD8_GFXCLK_CURVE= 1 << 1,
>   OD8_UCLK_MAX= 1 << 2,
> @@ -399,8 +398,7 @@ enum OD8_FEATURE_ID
>   OD8_FAN_ZERO_RPM_CONTROL= 1 << 9
>  };
>
> -enum OD8_SETTING_ID
> -{
> +enum OD8_SETTING_ID {
>   OD8_SETTING_GFXCLK_FMIN = 0,
>   OD8_SETTING_GFXCLK_FMAX,
>   OD8_SETTING_GFXCLK_FREQ1,
> --
> 2.17.1

RE: [PATCH 0/8] amdgpu/pm: Implement emit_clock_levels for arcturus,aldebaran

[Quan, Evan]

[AMD Official Use Only - General]

The series looks good to me.
Reviewed-by: Evan Quan evan.q...@amd.com<mailto:evan.q...@amd.com>

However better to split the changes of patch1 into two separate patches on your 
submission.
Replace print_clock_levels with emit_clock_levels for arcturus
  * replace .print_clk_levels with .emit_clk_levels in arcturus_ppt_funcs
  * added extra parameter int *offset
  * removed var size, uses arg *offset instead
  * removed call to smu_cmn_get_sysfs_buf
  * errors are returned to caller
  * returns 0 on success
Those changes are included in one patch.
additional incidental changes
  * changed type of var i, now to remove comparing mismatch types
  * renamed var s/now/cur_value/
  * switch statement default now returns -EINVAL
  * RAS Recovery returns -EBUSY
While those are included in another patch.

Same applied to patch5.

BR,
Evan
From: Powell, Darren 
Sent: Friday, July 28, 2023 3:51 AM
To: amd-gfx@lists.freedesktop.org
Cc: Lazar, Lijo ; Quan, Evan ; Yu, Lang 
; Huang, Ray 
Subject: Re: [PATCH 0/8] amdgpu/pm: Implement emit_clock_levels for 
arcturus,aldebaran

Hi all,
  Just looking for anyone who could RB or ACK this patch set so I can submit it?
Thanks
Darren

From: Powell, Darren mailto:darren.pow...@amd.com>>
Sent: Thursday, April 27, 2023 2:27 AM
To: amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org> 
mailto:amd-gfx@lists.freedesktop.org>>
Cc: Lazar, Lijo mailto:lijo.la...@amd.com>>; Quan, Evan 
mailto:evan.q...@amd.com>>; Yu, Lang 
mailto:lang...@amd.com>>; Huang, Ray 
mailto:ray.hu...@amd.com>>; 
david.ni...@amd.com<mailto:david.ni...@amd.com> 
mailto:david.ni...@amd.com>>; Powell, Darren 
mailto:darren.pow...@amd.com>>
Subject: [PATCH 0/8] amdgpu/pm: Implement emit_clock_levels for 
arcturus,aldebaran


amdgpu/pm: Implement emit_clock_levels for arcturus,aldebaran

== Description ==
Scnprintf use within the kernel is not recommended, but simple sysfs_emit 
replacement has
not been successful due to the page alignment requirement of the function. This 
patch
set implements a new api "emit_clock_levels" to facilitate passing both the 
base and
offset to the device rather than just the write pointer.

This patch set replaces print_clock_levels for arcturus and aldebaran platforms 
with
emit_clock_levels, and also optimizes the code to reduce the code duplication 
for each
different clock. This was spread into three parts to show more clearly the 
changes made
to the code, followed by combining the common code into a second switch 
statement.
It is similar to previous work on vega10 to implement emit_clk_levels
 commit a63e6b83 ("amdgpu/pm: Implement emit_clk_levels for vega10")
with the addition of the optimization to reduce code duplication.

== Patch Summary ==
   linux: 
(g...@gitlab.freedesktop.org:agd5f<mailto:g...@gitlab.freedesktop.org:agd5f>) 
origin/amd-staging-drm-next @ 2d8c6b82e241
+ 9a269da4c047 amdgpu/pm: Replace print_clock_levels with emit_clock_levels 
for arcturus
+ 51ce0fcc9599 amdgpu/pm: Optimize emit_clock_levels for arcturus - part 1
+ dcaa5b7551dd amdgpu/pm: Optimize emit_clock_levels for arcturus - part 2
+ 1d16d820e4ee amdgpu/pm: Optimize emit_clock_levels for arcturus - part 3
+ b374fbf6013d amdgpu/pm: Replace print_clock_levels with emit_clock_levels 
for aldebaran
+ 2ecf48d3e83c amdgpu/pm: Optimize emit_clock_levels for aldebaran - part 1
+ fd8c21e1d1e4 amdgpu/pm: Optimize emit_clock_levels for aldebaran - part 2
+ a67ce808f18c amdgpu/pm: Optimize emit_clock_levels for aldebaran - part 3

== System Summary ==
 * DESKTOP(AMD Ryzen9 7900 + NAVI10(731f/ca), BIOS: 1.11)
  + ISO(Ubuntu 22.04.2 LTS)
  + Kernel(6.1.11-20230412-fdoagd5f-g2d8c6b82e241)

== Test ==
AMDGPU_PCI_ADDR=`lspci -nn | grep "VGA\|Display" | cut -d " " -f 1`
AMDGPU_HWMON=`ls -la /sys/class/hwmon | grep $AMDGPU_PCI_ADDR | awk '{print 
$9}'`
HWMON_DIR=/sys/class/hwmon/${AMDGPU_HWMON}

lspci -nn | grep "VGA\|Display"  > $LOGFILE
printf 'OD enabled = %X\n' "$(( `cat 
/sys/module/amdgpu/parameters/ppfeaturemask` & 0x4000 ))" >> $LOGFILE
FILES="pp_od_clk_voltage
pp_dpm_sclk
pp_dpm_mclk
pp_dpm_pcie
pp_dpm_socclk
pp_dpm_fclk
pp_dpm_dcefclk
pp_dpm_vclk
pp_dpm_dclk "

for f in $FILES
do
  echo === $f === >> $LOGFILE
  cat $HWMON_DIR/device/$f >> $LOGFILE
done
cat $LOGFILE

Darren Powell (8):
  amdgpu/pm: Replace print_clock_levels with emit_clock_levels for
arcturus
  amdgpu/pm: Optimize emit_clock_levels for arcturus - part 1
  amdgpu/pm: Optimize emit_clock_levels for arcturus - part 2
  amdgpu/pm: Optimize emit_clock_levels for arcturus - part 3
  amdgpu/pm: Replace print_clock_levels with emit_clock_levels for
aldebaran
  amdgpu/pm: Optimize emit_clock_levels for aldebaran - part 1
  amdgpu/pm: Optimize emi

RE: [PATCH] drm/amd/pm: correct the pcie width for smu 13.0.0

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: Kenneth Feng 
> Sent: Thursday, July 27, 2023 7:41 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Feng, Kenneth
> 
> Subject: [PATCH] drm/amd/pm: correct the pcie width for smu 13.0.0
>
> correct the pcie width value in pp_dpm_pcie for smu 13.0.0
>
> Signed-off-by: Kenneth Feng 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index 232274423f9e..4bdbd3910e1f 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -1140,7 +1140,6 @@ static int smu_v13_0_0_print_clk_levels(struct
> smu_context *smu,
>   (OverDriveTableExternal_t *)smu-
> >smu_table.overdrive_table;
>   struct smu_13_0_dpm_table *single_dpm_table;
>   struct smu_13_0_pcie_table *pcie_table;
> - const int link_width[] = {0, 1, 2, 4, 8, 12, 16};
>   uint32_t gen_speed, lane_width;
>   int i, curr_freq, size = 0;
>   int32_t min_value, max_value;
> @@ -1256,7 +1255,7 @@ static int smu_v13_0_0_print_clk_levels(struct
> smu_context *smu,
>   (pcie_table->pcie_lane[i] == 6) ?
> "x16" : "",
>   pcie_table->clk_freq[i],
>   (gen_speed ==
> DECODE_GEN_SPEED(pcie_table->pcie_gen[i])) &&
> - (lane_width ==
> DECODE_LANE_WIDTH(link_width[pcie_table->pcie_lane[i]])) ?
> + (lane_width ==
> DECODE_LANE_WIDTH(pcie_table->pcie_lane[i])) ?
>   "*" : "");
>   break;
>
> --
> 2.34.1

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

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Limonciello, Mario 
> Sent: Monday, July 24, 2023 9:41 PM
> To: Andrew Lunn ; Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; mdaen...@redhat.com;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo
> ; jim.cro...@gmail.com; bellosili...@gmail.com;
> andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de;
> linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V7 4/9] wifi: mac80211: Add support for ACPI WBRF
>
> 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 ieee80211_check_wbrf_support(struct ieee80211_local *local) {
> >> +  struct wiphy *wiphy = local->hw.wiphy;
> >> +  struct device *dev;
> >> +
> >> +  if (!wiphy)
> >> +  return;
> >> +
> >> +  dev = wiphy->dev.parent;
> >> +  if (!dev)
> >> +  return;
> >> +
> >> +  local->wbrf_supported = wbrf_supported_producer(dev);
> >> +  dev_dbg(dev, "WBRF is %s supported\n",
> >> +  local->wbrf_supported ? "" : "not"); }
> >
> > This seems wrong. wbrf_supported_producer() is about "Should this
> > device report the frequencies it is using?" The answer to that depends
> > on a combination of: Are there consumers registered with the core, and
> > is the policy set so WBRF should take actions. > The problem here is,
> > you have no idea of the probe order. It could be this device probes
> > before others, so wbrf_supported_producer() reports false, but a few
> > second later would report true, once other devices have probed.
> >
> > It should be an inexpensive call into the core, so can be made every
> > time the channel changes. All the core needs to do is check if the
> > list of consumers is empty, and if not, check a Boolean policy value.
> >
> >   Andrew
>
> No, it's not a combination of whether consumers are registered with the core.
> If a consumer probes later it needs to know the current in use frequencies 
> too.
>
> The reason is because of this sequence of events:
> 1) Producer probes.
> 2) Producer selects a frequency.
> 3) Consumer probes.
> 4) Producer stays at same frequency.
>
> If the producer doesn't notify the frequency because a consumer isn't yet
> loaded then the consumer won't be able to get the current frequency.
Yes, exactly.

RE: [PATCH V7 0/9] Enable Wifi RFI interference mitigation feature support

[Quan, Evan]

[AMD Official Use Only - General]

Gentle ping on this series.

Hi Rafael and Andrew,

Can you help to check this latest series and share your thoughts if any?

BR,
Evan
> -Original Message-
> From: Quan, Evan 
> Sent: Wednesday, July 19, 2023 5:00 PM
> To: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; and...@lunn.ch
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org; Quan, Evan
> 
> Subject: [PATCH V7 0/9] Enable Wifi RFI interference mitigation feature
> support
>
> 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 Linux 6.4. With some brief introductions as
> below:
> Patch1 - 2:  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 (9):
>   drivers core: Add support for Wifi band RF mitigations
>   driver core: add ACPI based WBRF mechanism introduced by AMD
>   cfg80211: expose nl80211_chan_width_to_mhz for wide sharing
>   wifi: mac80211: Add support 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
>
>  drivers/acpi/Makefile |   2 +
>  drivers/acpi/amd_wbrf.c   | 282 ++
>  drivers/base/Kconfig  |  37 +++
>  drivers/base/Makefile |   1 +
>  drivers/base/wbrf.c   | 256 
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h   |   1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  19 ++
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 213 +
>  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 +
>  include/linux/acpi_amd_wbrf.h |  24 ++
>  include/linux/ieee80211.h |   1 +
>  include/linux/wbrf.h  |  72 +
>  include/net/cfg80211.h|   8 +
>  net/mac80211/Makefile |   2 +
>  net/mac80211/chan.c   |   9 +
>  net/mac80211/ieee80211_i.h|  19 ++
>  net/mac80211/main.c   |   2 +
>  net/mac80211/wbrf.c   | 103 +++
>  net/wireless/chan.c   |   3 +-
>  29 files changed, 1252 insertions(+), 6 deletions(-)
>  create mode 100644 drivers/acpi/amd_wbrf.c
>  create mode 100644 drivers/base/wbrf.c
>  create mode 100644 include/linux/acpi_amd_wbrf.h
>  create mode 100644 include/linux/wbrf.h
>  create mode 100644 net/mac80211/wbrf.c
>
> --
> 2.34.1

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

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Andrew Lunn 
> Sent: Tuesday, July 18, 2023 10:16 PM
> To: Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH V6 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> > The wbrf_supported_producer and wbrf_supported_consumer APIs seem
> > unnecessary for the generic implementation.
>
> I'm happy with these, once the description is corrected. As i said in another
> comment, 'can' should be replaced with 'should'. The device itself knows if it
> can, only the core knows if it should, based on the policy of if actions need 
> to
> be taken, and there are both providers and consumers registered with the
> core.
Sure, will update that in V7.

Evan
>
>Andrew

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

[Quan, Evan]

[AMD Official Use Only - General]

Personally I would like to treat the wbrf core as a water pool. Any stream can 
flow in. Also any needed can drain water from it at any time.
The way to allow producers to report only when there is consumer existing does 
not work. Since the consumer might come after the producer.
Just considering the scenario below:
Wifi core/driver started --> wifi driver reports its frequency in-use  --> 
proper action taken by wbrf core --> amdgpu driver(consumer) started
What should be the proper action taken by wbrf core then? Stop the producer to 
report its frequency in-use? That might lead consumer to never have a chance to 
know that.

The wbrf_supported_producer and wbrf_supported_consumer APIs seem unnecessary 
for the generic implementation.
But to support AMD ACPI implementation(or future device tree implementation), 
they are needed. The wbrf core needs to check whether the necessary AML codes 
are there.
It needs those information to judge whether a producer can report(will be 
accepted) or a consumer can retrieve needed information.

> > +struct wbrf_ranges_out {
> > +   u32 num_of_ranges;
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +} __packed;
>
> Seems odd using packed here. It is the only structure which is
> packed. I would also move the u32 after the struct so it is naturally
> aligned on 64 bit systems.
This is to align with the AMD ACPI implementation.
But I can make this AMD ACPI specific and bring a more generic version here.

Evan
> -Original Message-
> From: Andrew Lunn 
> Sent: Thursday, July 13, 2023 7:12 AM
> To: Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH V6 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> > +/**
> > + * wbrf_supported_producer - Determine if the device can report
> frequencies
> > + *
> > + * @dev: device pointer
> > + *
> > + * WBRF is used to mitigate devices that cause harmonic interference.
> > + * This function will determine if this device needs to report such
> frequencies.
>
> How is the WBRF core supposed to answer this question? That it knows
> there is at least one device which has registered with WBRF saying it
> can change its behaviour to avoid causing interference?
>
> Rather than "Determine if the device can report frequencies" should it be
> "Determine if the device should report frequencies"
>
> A WiFi device can always report frequencies, since it knows what
> frequency is it currently using. However, it is pointless making such
> reports if there is no device which can actually make use of the
> information.
>
> > +bool wbrf_supported_producer(struct device *dev)
> > +{
> > +   return true;
> > +}
>
> I found the default implementation of true being odd. It makes me
> wounder, what is the point of this call. I would expect this to see if
> a linked list is empty or not.
>
> > +/**
> > + * wbrf_supported_consumer - Determine if the device can react to
> frequencies
>
> This again seems odd. A device should know if it can react to
> frequencies or not. WBRF core should not need to tell it. What makes
> more sense to me is that this call is about a device telling the WBRF
> core it is able to react to frequencies. The WBRF core then can give a
> good answer to wbrf_supported_producer(), yes, i know of some other
> device who might be able to do something to avoid causing interference
> to you, so please do tell me about frequencies you want to use.
>
> What is missing here in this API is policy information. The WBRF core
> knows it has zero or more devices which can report what frequencies
> they are using, and it has zero or more devices which maybe can do
> something. But then you need policy to say this particular board needs
> any registered devices to actually do something because of poor
> shielding. Should this policy be as simple as a bool, or should it
> actually say the board has shielding issues for a list of frequencies?

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

[Quan, Evan]

[AMD Official Use Only - General]

Hi Wenyou,

I think you already got the greenlight(RB from Mario and ACK from me) to land 
the change.
Go ahead please.

Evan
> -Original Message-
> From: Yang, WenYou 
> Sent: Thursday, July 13, 2023 8:56 AM
> To: Yang, WenYou ; Deucher, Alexander
> ; Limonciello, Mario
> ; Koenig, Christian
> ; Pan, Xinhui ; Quan,
> Evan 
> Cc: Yuan, Perry ; Liang, Richard qi
> ; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: RE: [PATCH v2] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4
> to acquire gpu_metrics
>
> [AMD Official Use Only - General]
>
> Any comments? Any advice?
>
> Best Regards,
> Wenyou
>
> > -Original Message-
> > From: Wenyou Yang 
> > Sent: Wednesday, June 21, 2023 2:32 PM
> > To: Deucher, Alexander ; Limonciello, Mario
> > ; Koenig, Christian
> > ; Pan, Xinhui ; Quan,
> > Evan 
> > Cc: Yuan, Perry ; Liang, Richard qi
> > ; amd-gfx@lists.freedesktop.org; dri-
> > de...@lists.freedesktop.org; linux-ker...@vger.kernel.org; Yang,
> > WenYou 
> > Subject: [PATCH v2] drm/amd/pm: Vangogh: Add new gpu_metrics_v2_4 to
> > acquire gpu_metrics
> >
> > To acquire the voltage and current info from gpu_metrics interface,
> > but
> > gpu_metrics_v2_3 doesn't contain them, and to be backward compatible,
> > add new gpu_metrics_v2_4 structure.
> >
> > Reviewed-by: Mario Limonciello 
> > Acked-by: Evan Quan 
> > Signed-off-by: Wenyou Yang 
> > ---
> >  .../gpu/drm/amd/include/kgd_pp_interface.h|  69 +++
> >  .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c  | 109
> -
> > -
> >  drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c|   3 +
> >  3 files changed, 172 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > index 9f542f6e19ed..90989405eddc 100644
> > --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> > @@ -892,4 +892,73 @@ struct gpu_metrics_v2_3 {
> >   uint16_taverage_temperature_core[8]; //
> > average CPU core temperature on APUs
> >   uint16_taverage_temperature_l3[2];
> >  };
> > +
> > +struct gpu_metrics_v2_4 {
> > + struct metrics_table_header common_header;
> > +
> > + /* Temperature (unit: centi-Celsius) */
> > + uint16_ttemperature_gfx;
> > + uint16_ttemperature_soc;
> > + uint16_ttemperature_core[8];
> > + uint16_ttemperature_l3[2];
> > +
> > + /* Utilization (unit: centi) */
> > + uint16_taverage_gfx_activity;
> > + uint16_taverage_mm_activity;
> > +
> > + /* Driver attached timestamp (in ns) */
> > + uint64_tsystem_clock_counter;
> > +
> > + /* Power/Energy (unit: mW) */
> > + uint16_taverage_socket_power;
> > + uint16_taverage_cpu_power;
> > + uint16_taverage_soc_power;
> > + uint16_taverage_gfx_power;
> > + uint16_taverage_core_power[8];
> > +
> > + /* Average clocks (unit: MHz) */
> > + uint16_taverage_gfxclk_frequency;
> > + uint16_taverage_socclk_frequency;
> > + uint16_taverage_uclk_frequency;
> > + uint16_taverage_fclk_frequency;
> > + uint16_taverage_vclk_frequency;
> > + uint16_taverage_dclk_frequency;
> > +
> > + /* Current clocks (unit: MHz) */
> > + uint16_tcurrent_gfxclk;
> > + uint16_tcurrent_socclk;
> > + uint16_tcurrent_uclk;
> > + uint16_tcurrent_fclk;
> > + uint16_tcurrent_vclk;
> > + uint16_tcurrent_dclk;
> > + uint16_tcurrent_coreclk[8];
> > + uint16_tcurrent_l3clk[2];
> > +
> > + /* Throttle status (ASIC dependent) */
> > + uint32_tthrottle_status;
> > +
> > +   

RE: [PATCH 4/4] drm/amd: Drop amdgpu_device_aspm_support_quirk()

[Quan, Evan]

[AMD Official Use Only - General]

Patch1, 2, 3 are reviewed-by: Evan Quan 

For patch4, it seems not quite right(at least for the naming).
Since although the ASPM is the prerequisite for pcie/lclk dpm features.
But the changes involved here are really for aspm feature disablement.
I mean even if pcie dynamic lane/speed switching is not supported, aspm feature 
can be still enabled.
So, using "amdgpu_device_pcie_dynamic_switching_supported" for the 
determination whether aspm feature can be enabled seems not proper.

Evan
> -Original Message-
> From: Limonciello, Mario 
> Sent: Saturday, July 8, 2023 10:26 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Limonciello, Mario
> 
> Subject: [PATCH 4/4] drm/amd: Drop amdgpu_device_aspm_support_quirk()
>
> NV and VI currently set up a quirk to not enable ASPM on Alder Lake
> systems, but the issue appears to be tied to hosts without support
> for dynamic speed switching. Migrate both of these over to use
> amdgpu_device_pcie_dynamic_switching_supported() instead and drop
> amdgpu_device_aspm_support_quirk().
>
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 ---
>  drivers/gpu/drm/amd/amdgpu/nv.c|  5 -
>  drivers/gpu/drm/amd/amdgpu/vi.c|  5 -
>  4 files changed, 8 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 813713f42d5e..6ecf42c4c970 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1315,7 +1315,6 @@ int amdgpu_device_pci_reset(struct
> amdgpu_device *adev);
>  bool amdgpu_device_need_post(struct amdgpu_device *adev);
>  bool amdgpu_device_pcie_dynamic_switching_supported(void);
>  bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
> -bool amdgpu_device_aspm_support_quirk(void);
>
>  void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64
> num_bytes,
> u64 num_vis_bytes);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7314529553f6..a9e757f899f2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1505,17 +1505,6 @@ bool amdgpu_device_should_use_aspm(struct
> amdgpu_device *adev)
>   return pcie_aspm_enabled(adev->pdev);
>  }
>
> -bool amdgpu_device_aspm_support_quirk(void)
> -{
> -#if IS_ENABLED(CONFIG_X86)
> - struct cpuinfo_x86 *c = &cpu_data(0);
> -
> - return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
> -#else
> - return true;
> -#endif
> -}
> -
>  /* if we get transitioned to only one device, take VGA back */
>  /**
>   * amdgpu_device_vga_set_decode - enable/disable vga decode
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
> b/drivers/gpu/drm/amd/amdgpu/nv.c
> index 51523b27a186..71bc5b2f36cf 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> @@ -527,7 +527,10 @@ static int nv_set_vce_clocks(struct amdgpu_device
> *adev, u32 evclk, u32 ecclk)
>
>  static void nv_program_aspm(struct amdgpu_device *adev)
>  {
> - if (!amdgpu_device_should_use_aspm(adev)
> || !amdgpu_device_aspm_support_quirk())
> + if (!amdgpu_device_should_use_aspm(adev))
> + return;
> +
> + if (!amdgpu_device_pcie_dynamic_switching_supported())
>   return;
>
>   if (!(adev->flags & AMD_IS_APU) &&
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 6a8494f98d3e..f44c78e69b7f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1124,7 +1124,10 @@ static void vi_program_aspm(struct
> amdgpu_device *adev)
>   bool bL1SS = false;
>   bool bClkReqSupport = true;
>
> - if (!amdgpu_device_should_use_aspm(adev)
> || !amdgpu_device_aspm_support_quirk())
> + if (!amdgpu_device_should_use_aspm(adev))
> + return;
> +
> + if (!amdgpu_device_pcie_dynamic_switching_supported())
>   return;
>
>   if (adev->flags & AMD_IS_APU ||
> --
> 2.34.1

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

[Quan, Evan]

[AMD Official Use Only - General]

Hi Andrew,

I discussed with Mario about your proposal/concerns here.
We believe some changes below might address your concerns.
- place/move the wbrf_supported_producer check inside 
acpi_amd_wbrf_add_exclusion and acpi_amd_wbrf_add_exclusion
- place the wbrf_supported_consumer check inside 
acpi_amd_wbrf_retrieve_exclusions
So that the wbrf_supported_producer and wbrf_supported_consumer can be dropped.
We made some prototypes and even performed some tests which showed technically 
it is absolutely practicable.

However, we found several issues with that.
- The overhead caused by the extra _producer/_consumer check on every calling 
of wbrf_add/remove/retrieve_ecxclusion.
  Especially when you consider there might be multiple producers and consumers 
in the system at the same time. And some of
  them might do in-use band/frequency switching frequently.
- Some extra costs caused by the "know it only at the last minute". For 
example, to support WBRF, amdgpu driver needs some preparations: install the 
notification hander,
  setup the delay workqueue(to handle possible events flooding) and even notify 
firmware engine to be ready. However, only on the 1st notification receiving,
  it is realized(reported by wbrf_supported_consumer check) the WBRF feature is 
actually not supported. All those extra costs can be actually avoided if we can 
know the WBRF is not supported at first.
  This could happen to other consumers and producers too.

After a careful consideration, we think the changes do not benefit us much. It 
does not deserve us to spend extra efforts.
Thus we would like to stick with original implementations. That is to have 
wbrf_supported_producer and wbrf_supported_consumer interfaces exposed.
Then other drivers/subsystems can do necessary wbrf support check in advance 
and coordinate their actions accordingly.
Please let us know your thoughts.

BR,
Evan
> -Original Message-
> From: Andrew Lunn 
> Sent: Tuesday, July 4, 2023 9:07 PM
> To: Quan, Evan 
> Cc: raf...@kernel.org; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> > > What is the purpose of this stage? Why would it not be supported for
> > > this device?
> > This is needed for wbrf support via ACPI mechanism. If BIOS(AML code)
> > does not support the wbrf adding/removing for some device, it should
> speak that out so that the device can be aware of that.
>
> How much overhead is this adding? How deep do you need to go to find the
> BIOS does not support it? And how often is this called?
>
> Where do we want to add complexity? In the generic API? Or maybe a little
> deeper in the ACPI specific code?
>
>Andrew

RE: [RFC 1/2] drm/amd: Extend Intel ASPM quirk to all dGPUs

[Quan, Evan]

[AMD Official Use Only - General]

One small nitpick:
It seems there is missing a default clause for the switch statement.
Will that hit the compile warning about "a switch statement must have a default 
clause"?
With that checked, the series is reviewed-by: Evan Quan 

Evan
> -Original Message-
> From: amd-gfx  On Behalf Of Mario
> Limonciello
> Sent: Thursday, July 6, 2023 2:07 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: koba...@canonical.com; Limonciello, Mario
> 
> Subject: [RFC 1/2] drm/amd: Extend Intel ASPM quirk to all dGPUs
>
> More failures are reported across additional products and so it seems
> unless we have a handle on the fundmental ASPM incompatibilities with
> Intel host and AMD dGPU, we should not allow them on problematic hosts.
>
> Fixes: 0064b0ce85bb ("drm/amd/pm: enable ASPM by default")
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h|  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 39 +++---
> 
>  drivers/gpu/drm/amd/amdgpu/nv.c|  2 +-
>  drivers/gpu/drm/amd/amdgpu/vi.c|  2 +-
>  4 files changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index dc4dc1446a19..294a549e7499 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1314,7 +1314,6 @@ void amdgpu_device_pci_config_reset(struct
> amdgpu_device *adev);
>  int amdgpu_device_pci_reset(struct amdgpu_device *adev);
>  bool amdgpu_device_need_post(struct amdgpu_device *adev);
>  bool amdgpu_device_should_use_aspm(struct amdgpu_device *adev);
> -bool amdgpu_device_aspm_support_quirk(void);
>
>  void amdgpu_cs_report_moved_bytes(struct amdgpu_device *adev, u64
> num_bytes,
> u64 num_vis_bytes);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 7f069e1731fe..ef22a0a6065e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1458,6 +1458,30 @@ bool amdgpu_device_need_post(struct
> amdgpu_device *adev)
>   return true;
>  }
>
> +static bool amdgpu_device_aspm_support_quirk(void)
> +{
> +#if IS_ENABLED(CONFIG_X86)
> + struct cpuinfo_x86 *c = &cpu_data(0);
> +
> + if (c->x86 != 6)
> + return true;
> +
> + switch (c->x86_model) {
> + /* Problems reported for Alder Lake
> +  * Volcanic Islands:
> +  *   https://gitlab.freedesktop.org/drm/amd/-/issues/1885
> +  *   e02fe3bc7aba2 ("drm/amdgpu: vi: disable ASPM on Intel Alder
> Lake based systems")
> +  * Navi 1x cards:
> +  *   https://gitlab.freedesktop.org/drm/amd/-/issues/2458
> +  *   c08c079692da0 ("drm/amdgpu/nv: Apply ASPM quirk on Intel
> ADL + AMD Navi")
> +  */
> + case INTEL_FAM6_ALDERLAKE:
> + return false;
> + }
> +#endif
> + return true;
> +}
> +
>  /**
>   * amdgpu_device_should_use_aspm - check if the device should program
> ASPM
>   *
> @@ -1480,18 +1504,9 @@ bool amdgpu_device_should_use_aspm(struct
> amdgpu_device *adev)
>   default:
>   return false;
>   }
> - return pcie_aspm_enabled(adev->pdev);
> -}
> -
> -bool amdgpu_device_aspm_support_quirk(void)
> -{
> -#if IS_ENABLED(CONFIG_X86)
> - struct cpuinfo_x86 *c = &cpu_data(0);
> -
> - return !(c->x86 == 6 && c->x86_model == INTEL_FAM6_ALDERLAKE);
> -#else
> - return true;
> -#endif
> + if (!pcie_aspm_enabled(adev->pdev))
> + return false;
> + return amdgpu_device_aspm_support_quirk();
>  }
>
>  /* if we get transitioned to only one device, take VGA back */
> diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c
> b/drivers/gpu/drm/amd/amdgpu/nv.c
> index 51523b27a186..4f8e696d9ba2 100644
> --- a/drivers/gpu/drm/amd/amdgpu/nv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/nv.c
> @@ -527,7 +527,7 @@ static int nv_set_vce_clocks(struct amdgpu_device
> *adev, u32 evclk, u32 ecclk)
>
>  static void nv_program_aspm(struct amdgpu_device *adev)
>  {
> - if (!amdgpu_device_should_use_aspm(adev)
> || !amdgpu_device_aspm_support_quirk())
> + if (!amdgpu_device_should_use_aspm(adev))
>   return;
>
>   if (!(adev->flags & AMD_IS_APU) &&
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c
> b/drivers/gpu/drm/amd/amdgpu/vi.c
> index 6a8494f98d3e..c413cac369e4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1124,7 +1124,7 @@ static void vi_program_aspm(struct
> amdgpu_device *adev)
>   bool bL1SS = false;
>   bool bClkReqSupport = true;
>
> - if (!amdgpu_device_should_use_aspm(adev)
> || !amdgpu_device_aspm_support_quirk())
> + if (!amdgpu_device_should_use_aspm(adev))
>   return;
>
>   if (adev->flags & AMD_IS_APU ||
> --
> 2.34.1

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

[Quan, Evan]

[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...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> 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 */
> > +/*
> > + * Wifi Band Exclusion Interface
> > + * Copyright (C) 2023 Advanced Micro Devices
> > + */
> > +
> > +#ifndef _LINUX_WBRF_H
> > +#define _LINUX_WBRF_H
> > +
> > +#include 
> > +
> > +/* Maximum number of wbrf ranges */
> > +#define MAX_NUM_OF_WBRF_RANGES 11
> > +
> > +struct exclusion_range {
> > +   /* start and end point of the frequency range in Hz */
> > +   uint64_tstart;
> > +   uint64_tend;
> > +};
> > +
> > +struct exclusion_range_pool {
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +   uint64_t
>   ref_counter[MAX_NUM_OF_WBRF_RANGES];
> > +};
> > +
> > +struct wbrf_ranges_in {
> > +   /* valid entry: `start` and `end` filled with non-zero values */
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +};
> > +
> > +struct wbrf_ranges_out {
> > +   uint32_tnum_of_ranges;
> > +   struct exclusion_range  band_list[MAX_NUM_OF_WBRF_RANGES];
> > +} __packed;
> > +
> > +enum wbrf_notifier_actions {
> > +   WBRF_CHANGED,
> > +};
>
> Hi Evan,
>
> checkpatch suggests that u64 and u32 might be more appropriate types here,
> as they are Kernel types, whereas the ones use are user-space types.
Thanks for pointing this out. Will update them accordingly.

Evan
>
> ...

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

[Quan, Evan]

[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...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; mdaen...@redhat.com;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo
> ; jim.cro...@gmail.com; bellosili...@gmail.com;
> andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V5 1/9] drivers core: Add support for Wifi band RF
> mitigations
>
> 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 introduced a mechanism that devices can use
> > to notify active use of particular frequencies so that other devices
> > can make relative internal adjustments as necessary to avoid this resonance.
> >
> > In order for a device to support this, the expected flow for device
> > driver or subsystems:
> >
> > Drivers/subsystems contributing frequencies:
> >
> > 1) During probe, check `wbrf_supported_producer` to see if WBRF
> supported
> > for the device.
> > 2) If adding frequencies, then call `wbrf_add_exclusion` with the
> > start and end ranges of the frequencies.
> > 3) If removing frequencies, then call `wbrf_remove_exclusion` with
> > start and end ranges of the frequencies.
> >
> > Drivers/subsystems responding to frequencies:
> >
> > 1) During probe, check `wbrf_supported_consumer` to see if WBRF is
> supported
> > for the device.
> > 2) Call the `wbrf_retrieve_exclusions` to retrieve the current
> > exclusions on receiving an ACPI notification for a new frequency
> > change.
> >
> > Co-developed-by: Mario Limonciello 
> > Signed-off-by: Mario Limonciello 
> > Co-developed-by: Evan Quan 
> > Signed-off-by: Evan Quan 
> > --
> > v4->v5:
> >- promote this to be a more generic solution with input argument taking
> >  `struct device` and provide better scalability to support non-ACPI
> >  scenarios(Andrew)
> >- update the APIs naming and some other minor fixes(Rafael)
> > ---
> >   drivers/base/Kconfig  |   8 ++
> >   drivers/base/Makefile |   1 +
> >   drivers/base/wbrf.c   | 227
> ++
> >   include/linux/wbrf.h  |  65 
> >   4 files changed, 301 insertions(+)
> >   create mode 100644 drivers/base/wbrf.c
> >   create mode 100644 include/linux/wbrf.h
> >
> > diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index
> > 2b8fd6bb7da0..5b441017b225 100644
> > --- a/drivers/base/Kconfig
> > +++ b/drivers/base/Kconfig
> > @@ -242,4 +242,12 @@ config FW_DEVLINK_SYNC_STATE_TIMEOUT
> >   command line option on every system/board your kernel is expected
> to
> >   work on.
> >
> > +config WBRF
> > +   bool "Wifi band RF mitigation mechanism"
> > +   default n
> > +   help
> > + Wifi band RF mitigation mechanism allows multiple drivers from
> > + different domains to notify the frequencies in use so that hardware
> > + can be reconfigured to avoid harmonic conflicts.
> > +
> >   endmenu
> > diff --git a/drivers/base/Makefile b/drivers/base/Makefile index
> > 3079bfe53d04..c844f68a6830 100644
> > --- a/drivers/base/Makefile
> > +++ b/drivers/base/Makefile
> > @@ -26,6 +26,7 @@ obj-$(CONFIG_GENERIC_MSI_IRQ) += platform-msi.o
> >   obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
> >   obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
> >   obj-$(CONFIG_ACPI) += physical_location.o
> > +obj-$(CONFIG_WBRF) += wbrf.o
> >
> >   obj-y += test/
> >
> > diff --git a/drivers/base/wbrf.c b/drivers/base/wbrf.c new file mode
> > 100644 index ..2163a8ec8a9a
> > --- /dev/null
> > +++ b/drivers/base/wbrf.c
> > @@ -0,0 +1,227 @@
> > +// SPDX-License-Identifier: GPL-2.0
> >

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

[Quan, Evan]

[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...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: 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?
This is needed for wbrf support via ACPI mechanism. If BIOS(AML code) does not 
support the wbrf adding/removing for some device,
it should speak that out so that the device can be aware of that.
>
> > +#ifdef CONFIG_WBRF
> > +bool wbrf_supported_producer(struct device *dev); int
> > +wbrf_add_exclusion(struct device *adev,
> > +  struct wbrf_ranges_in *in);
> > +int wbrf_remove_exclusion(struct device *dev,
> > + struct wbrf_ranges_in *in);
> > +int wbrf_retrieve_exclusions(struct device *dev,
> > +struct wbrf_ranges_out *out); bool
> > +wbrf_supported_consumer(struct device *dev);
> > +
> > +int wbrf_register_notifier(struct notifier_block *nb); int
> > +wbrf_unregister_notifier(struct notifier_block *nb); #else static
> > +inline bool wbrf_supported_producer(struct device *dev) { return
> > +false; } static inline int wbrf_add_exclusion(struct device *adev,
> > +struct wbrf_ranges_in *in) { return -
> ENODEV; } static inline
> > +int wbrf_remove_exclusion(struct device *dev,
> > +   struct wbrf_ranges_in *in) { return -
> ENODEV; }
>
> The normal aim of stubs is that so long as it is not expected to be fatal if 
> the
> functionality is missing, the caller should not care if it is missing. So i 
> would
> expect these to return 0, indicating everything worked as expected.
Sure, that makes sense.
>
> > +static inline int wbrf_retrieve_exclusions(struct device *dev,
> > +  struct wbrf_ranges_out *out)
> { return -ENODEV; }
>
> This is more complex. Ideally you want to return an empty set, so there is
> nothing to do. So i think the stub probably wants to do a memset and then
> return 0.
Right, will update it accordingly.
>
> > +static inline bool wbrf_supported_consumer(struct device *dev) {
> > +return false; } static inline int wbrf_register_notifier(struct
> > +notifier_block *nb) { return -ENODEV; } static inline int
> > +wbrf_unregister_notifier(struct notifier_block *nb) { return -ENODEV;
> > +}
>
> And these can just return 0.
Will update it.

Evan
>
> Andrew

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

[Quan, Evan]

[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.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; mdaen...@redhat.com;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo
> ; jim.cro...@gmail.com; bellosili...@gmail.com;
> andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de;
> linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: 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 easier
> > to land through multiple trees; so I have a slight leaning in that 
> > direction.
>
> #ifdef in C files is generally not liked because it makes build testing 
> harder.
> There are more permutations to build. It is better to use
>
> if (IS_ENABLED(CONFIG_WBTR)) {
> }
>
> so that the code is compiled, and them throw away because
> IS_ENABLED(CONFIG_WBTR) evaluates to false.
>
> However, if the stubs are done correctly, the driver should not care. I doubt
> this is used in any sort of hot path where every instruction counts.
OK, will update as suggested.

Evan
>
>   Andrew

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

[Quan, Evan]

[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...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: 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.elements = &argv4[1];
> > +   argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER;
> > +   argv4[arg_idx++].integer.value = num_of_ranges;
> > +   argv4[arg_idx].integer.type = ACPI_TYPE_INTEGER;
> > +   argv4[arg_idx++].integer.value = action;
>
> There is a lot of magic numbers in that kzalloc. It is being used as an array,
> kcalloc() would be a good start to make it more readable.
> Can some #define's be used to explain what the other numbers mean?
Sure, will update accordingly.
>
> > +   /*
> > +* Bit 0 indicates whether there's support for any functions other than
> > +* function 0.
> > +*/
>
> Please make use of the BIT macro to give the different bits informative names.
Sure.
>
> > +   if ((mask & 0x1) && (mask & funcs) == funcs)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
>
> > +int acpi_amd_wbrf_retrieve_exclusions(struct device *dev,
> > + struct wbrf_ranges_out *out) {
> > +   struct acpi_device *adev = ACPI_COMPANION(dev);
> > +   union acpi_object *obj;
> > +
> > +   if (!adev)
> > +   return -ENODEV;
> > +
> > +   obj = acpi_evaluate_wbrf(adev->handle,
> > +WBRF_REVISION,
> > +WBRF_RETRIEVE);
> > +   if (!obj)
> > +   return -EINVAL;
> > +
> > +   WARN(obj->buffer.length != sizeof(*out),
> > +   "Unexpected buffer length");
> > +   memcpy(out, obj->buffer.pointer, obj->buffer.length);
>
> You WARN, and then overwrite whatever i passed the end of out?  Please at
> least use min(obj->buffer.length, sizeof(*out)), but better still:
>
>if (obj->buffer.length != sizeof(*out)) {
>  dev_err(dev, "BIOS FUBAR, ignoring wrong sized WBRT information");
>return -EINVAL;
>}
OK. Sounds reasonable. Will update as suggested.
>
> > +#if defined(CONFIG_WBRF_GENERIC)
> >  static struct exclusion_range_pool wbrf_pool;
> >
> >  static int _wbrf_add_exclusion_ranges(struct wbrf_ranges_in *in) @@
> > -89,6 +92,7 @@ static int _wbrf_retrieve_exclusion_ranges(struct
> > wbrf_ranges_out *out)
> >
> > return 0;
> >  }
> > +#endif
>
> I was expecting you would keep these tables, and then call into the BIOS as
> well. Having this table in debugfs seems like a useful thing to have for
> debugging the BIOS.
I'm not sure. Since these interfaces what we designed now kind of serve as a 
library.
When and where the debugfs should be created will be quite tricky.
>
> > +#ifdef CONFIG_WBRF_AMD_ACPI
> > +#else
> > +static inline bool
> > +acpi_amd_wbrf_supported_consumer(struct device *dev) { return false;
> > +} static inline bool acpi_amd_wbrf_supported_producer(struct device
> > +*dev) {return false; } static inline int
> > +acpi_amd_wbrf_remove_exclusion(struct device *dev,
> > +  struct wbrf_ranges_in *in) { return -ENODEV; }
> static
> > +inline int acpi_amd_wbrf_add_exclusion(struct device *dev,
> > +   struct wbrf_ranges_in *in) { return -ENODEV; } 
> > static
> inline
> > +int acpi_amd_wbrf_retrieve_exclusions(struct device *dev,
> > + struct wbrf_ranges_out *out) { return -
> ENODEV; }
>
> Do you actually need these stub versions?
Yes, these can be dropped. Let me update accordingly.

Evan
>
>   Andrew

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

[Quan, Evan]

[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...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; Limonciello, Mario ;
> mdaen...@redhat.com; maarten.lankho...@linux.intel.com;
> tzimmerm...@suse.de; hdego...@redhat.com; jingyuwang_...@163.com;
> Lazar, Lijo ; jim.cro...@gmail.com;
> bellosili...@gmail.com; andrealm...@igalia.com; t...@redhat.com;
> j...@jsg.id.au; a...@arndb.de; linux-ker...@vger.kernel.org; linux-
> a...@vger.kernel.org; amd-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org
> Subject: 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);
> > +
> > +   *start = center_freq - bandwidth / 2;
> > +   *end = center_freq + bandwidth / 2;
> > +
> > +   /* Frequency in HZ is expected */
> > +   *start = KHZ_TO_HZ(*start);
> > +   *end = KHZ_TO_HZ(*end);
> > +}
>
> This seems pretty generic, so maybe it should be moved into the shared code?
> It can then become a NOP when the functionality if disabled.
The shared code you mean is some place around mac80211?
Actually, there are two similar variants existed already: 
cfg80211_get_start_freq and cfg80211_get_end_freq.
The outputs of them are really what most mac80211 logics care.
The new API here is unlikely to be shared by other mac80211 part.
So, I suppose placing it here(only in wbrf.c) seems proper.
How do you think?

Evan
>
>   Andrew

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

[Quan, Evan]

[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 1:16 AM
> To: Limonciello, Mario 
> Cc: Rafael J. Wysocki ; Quan, Evan
> ; l...@kernel.org; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; johan...@sipsolutions.net;
> da...@davemloft.net; eduma...@google.com; k...@kernel.org;
> pab...@redhat.com; mdaen...@redhat.com;
> maarten.lankho...@linux.intel.com; tzimmerm...@suse.de;
> hdego...@redhat.com; jingyuwang_...@163.com; Lazar, Lijo
> ; jim.cro...@gmail.com; bellosili...@gmail.com;
> andrealm...@igalia.com; t...@redhat.com; j...@jsg.id.au; a...@arndb.de;
> linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH V4 1/8] drivers/acpi: Add support for Wifi band RF
> mitigations
>
> On Fri, Jun 23, 2023 at 6:48 PM Limonciello, Mario
>  wrote:
> >
> >
> > 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 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 an ACPI based mechanism that
> > >>>> devices can use to notify active use of particular frequencies so
> > >>>> that devices can make relative internal adjustments as necessary
> > >>>> to avoid this resonance.
> > >>>>
> > >>>> In order for a device to support this, the expected flow for
> > >>>> device driver or subsystems:
> > >>>>
> > >>>> Drivers/subsystems contributing frequencies:
> > >>>>
> > >>>> 1) During probe, check `wbrf_supported_producer` to see if WBRF
> > >>>> supported
> > >>> The prefix should be acpi_wbrf_ or acpi_amd_wbrf_ even, so it is
> > >>> clear that this uses ACPI and is AMD-specific.
> > >> I guess if we end up with an intermediary library approach
> > >> wbrf_supported_producer makes sense and that could call acpi_wbrf_*.
> > >>
> > >> But with no intermediate library your suggestion makes sense.
> > >>
> > >> I would prefer not to make it acpi_amd as there is no reason that
> > >> this exact same problem couldn't happen on an Wifi 6e + Intel SOC +
> > >> AMD dGPU design too and OEMs could use the same mitigation
> > >> mechanism as Wifi6e + AMD SOC + AMD dGPU too.
> > > The mitigation mechanism might be the same, but the AML interface
> > > very well may be different.
> >
> >
> > Right.  I suppose right now we should keep it prefixed as "amd", and
> > if it later is promoted as a standard it can be renamed.
> >
> >
> > >
> > > My point is that this particular interface is AMD-specific ATM and
> > > I'm not aware of any plans to make it "standard" in some way.
> >
> >
> > Yeah; this implementation is currently AMD specific AML, but I expect
> > the exact same AML would be delivered to OEMs using the dGPUs.
> >
> >
> > >
> > > Also if the given interface is specified somewhere, it would be good
> > > to have a pointer to that place.
> >
> >
> > It's a code first implementation.  I'm discussing with the owners when
> > they will release it.
> >
> >
> > >
> > >>> Whether or not there needs to be an intermediate library wrapped
> > >>> around this is a different matter.
> > > IMO individual drivers should not be expected to use this interface
> > > directly, as that would add to boilerplate code and overall bloat.
> >
> > The thing is the ACPI method is not a platform method.  It's a
>

RE: [PATCH 2/2] drm/amd/pm: avoid unintentional shutdown due to temperature momentary fluctuation

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Lazar, Lijo 
> Sent: Monday, June 26, 2023 7:54 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 2/2] drm/amd/pm: avoid unintentional shutdown due to
> temperature momentary fluctuation
>
>
>
> On 6/26/2023 1:17 PM, Evan Quan wrote:
> > An intentional delay is added on soft ctf triggered. Then there will
> > be a double check for the GPU temperature before taking further
> > action. This can avoid unintended shutdown due to temperature
> > momentary fluctuation.
> >
> > Signed-off-by: Evan Quan 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  3 ++
> >   .../gpu/drm/amd/pm/powerplay/amd_powerplay.c  | 48
> +++
> >   .../drm/amd/pm/powerplay/hwmgr/smu_helper.c   | 27 ---
> >   drivers/gpu/drm/amd/pm/powerplay/inc/hwmgr.h  |  2 +
> >   drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 34
> +
> >   drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  2 +
> >   .../gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c|  9 +---
> >   .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c|  9 +---
> >   8 files changed, 102 insertions(+), 32 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index e459381dc759..5ef1f31e703c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -287,6 +287,9 @@ extern int amdgpu_user_partt_mode;
> >   #define AMDGPU_SMARTSHIFT_MAX_BIAS (100)
> >   #define AMDGPU_SMARTSHIFT_MIN_BIAS (-100)
> >
> > +/* Extra time delay(in ms) to eliminate the influence of temperature
> momentary fluctuation */
> > +#define AMDGPU_SWCTF_EXTRA_DELAY   50
>
> I think a delay of 10-15ms is good enough to filter out any spike.
50ms is required by our CE team for supporting the customer. It is also aligned 
with Windows side.
Considering we cannot guard that(10-15ms is good), I think it's better to stick 
to the 50ms recommended setting.
How do you think?

Evan
>
> With that change, the series is
>   Reviewed-by: Lijo Lazar 
>
> Thanks,
> Lijo
>
> > +
> >   struct amdgpu_xcp_mgr;
> >   struct amdgpu_device;
> >   struct amdgpu_irq_src;
> > diff --git a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > index 11b7b4cffaae..ff360c699171 100644
> > --- a/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > +++ b/drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
> > @@ -26,6 +26,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include "amd_shared.h"
> >   #include "amd_powerplay.h"
> >   #include "power_state.h"
> > @@ -91,6 +92,45 @@ static int pp_early_init(void *handle)
> > return 0;
> >   }
> >
> > +static void pp_swctf_delayed_work_handler(struct work_struct *work) {
> > +   struct pp_hwmgr *hwmgr =
> > +   container_of(work, struct pp_hwmgr,
> swctf_delayed_work.work);
> > +   struct amdgpu_device *adev = hwmgr->adev;
> > +   struct amdgpu_dpm_thermal *range =
> > +   &adev->pm.dpm.thermal;
> > +   uint32_t gpu_temperature, size;
> > +   int ret;
> > +
> > +   /*
> > +* If the hotspot/edge temperature is confirmed as below SW CTF
> setting point
> > +* after the delay enforced, nothing will be done.
> > +* Otherwise, a graceful shutdown will be performed to prevent
> further damage.
> > +*/
> > +   if (range->sw_ctf_threshold &&
> > +   hwmgr->hwmgr_func->read_sensor) {
> > +   ret = hwmgr->hwmgr_func->read_sensor(hwmgr,
> > +
> AMDGPU_PP_SENSOR_HOTSPOT_TEMP,
> > +&gpu_temperature,
> > +&size);
> > +   /*
> > +* For some legacy ASICs, hotspot temperature retrieving
> might be not
> > +* supported. Check the edge temperature instead then.
> > +*/
> > +   if (ret == -EOPNOTSUPP)
> > +   ret = hwmgr->hwmgr_func->read_sensor(hwmgr,
> > +
> AMDGPU_PP_SENSOR_EDGE_TEMP,
> > +
> &gpu_temperature,
> > +&size);
> > +   if (!ret && gpu_temperature / 1000 < range-
> >sw_ctf_threshold)
> > +  

RE: [PATCH V3 1/7] drivers/acpi: Add support for Wifi band RF mitigations

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Limonciello, Mario 
> Sent: Monday, June 19, 2023 10:04 AM
> To: Quan, Evan 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Lazar, Lijo 
> Subject: Re: [PATCH V3 1/7] drivers/acpi: Add support for Wifi band RF
> mitigations
>
> On 6/16/23 01:57, 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 clocks with local radio module
> > frequency bands used by Wifi 6/6e/7.
> >
> > To mitigate this, AMD has introduced an ACPI based mechanism that
> > devices can use to notify active use of particular frequencies so that
> > devices can make relative internal adjustments as necessary to avoid
> > this resonance.
> >
> > In order for a device to support this, the expected flow for device
> > driver or subsystems:
> >
> > Drivers/subsystems contributing frequencies:
> >
> > 1) During probe, check `wbrf_supported_producer` to see if WBRF
> supported
> > for the device.
> > 2) If adding frequencies, then call `wbrf_add_exclusion` with the
> > start and end ranges of the frequencies.
> > 3) If removing frequencies, then call `wbrf_remove_exclusion` with
> > start and end ranges of the frequencies.
> >
> > Drivers/subsystems responding to frequencies:
> >
> > 1) During probe, check `wbrf_supported_consumer` to see if WBRF is
> supported
> > for the device.
> > 2) Call the `wbrf_retrieve_exclusions` to retrieve the current
> > exclusions on receiving an ACPI notification for a new frequency
> > change.
> >
> > Signed-off-by: Mario Limonciello 
> > Co-developed-by: Evan Quan 
> > Signed-off-by: Evan Quan 
> > --
> > v1->v2:
> >- move those wlan specific implementations to net/mac80211(Mario)
> > ---
> >   drivers/acpi/Kconfig |   7 ++
> >   drivers/acpi/Makefile|   2 +
> >   drivers/acpi/acpi_wbrf.c | 215
> +++
> >   include/linux/wbrf.h |  55 ++
> >   4 files changed, 279 insertions(+)
> >   create mode 100644 drivers/acpi/acpi_wbrf.c
> >   create mode 100644 include/linux/wbrf.h
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index
> > ccbeab9500ec..9ee7c7dcc3e6 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -611,3 +611,10 @@ config X86_PM_TIMER
> >
> >   You should nearly always say Y here because many modern
> >   systems require this timer.
> > +
> > +config ACPI_WBRF
> > +   bool "ACPI Wifi band RF mitigation mechanism"
> > +   help
> > + Wifi band RF mitigation mechanism allows multiple drivers from
> > + different domains to notify the frequencies in use so that hardware
> > + can be reconfigured to avoid harmonic conflicts.
> > \ No newline at end of file
>
> There should be a newline at the end of the Kconfig file.
OK, will add that.

Evan
>
> > diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index
> > feb36c0b9446..be173e76aa62 100644
> > --- a/drivers/acpi/Makefile
> > +++ b/drivers/acpi/Makefile
> > @@ -131,3 +131,5 @@ obj-y   += dptf/
> >   obj-$(CONFIG_ARM64)   += arm64/
> >
> >   obj-$(CONFIG_ACPI_VIOT)   += viot.o
> > +
> > +obj-$(CONFIG_ACPI_WBRF)+= acpi_wbrf.o
> > \ No newline at end of file
> > diff --git a/drivers/acpi/acpi_wbrf.c b/drivers/acpi/acpi_wbrf.c new
> > file mode 100644 index ..8c275998ac29
> > --- /dev/null
> > +++ b/drivers/acpi/acpi_wbrf.c
> > @@ -0,0 +1,215 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * AMD Wifi Band Exclusion Interface
> > + * Copyright (C) 2023 Advanced Micro Devices
> > + *
> > + */
> > +
> > +#include 
> > +
> > +/* functions */
> > +#define WBRF_RECORD0x1
> > +#define WBRF_RETRIE

RE: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Limonciello, Mario 
> Sent: Monday, June 19, 2023 10:17 AM
> To: Quan, Evan 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Lazar, Lijo 
> Subject: Re: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF
>
> On 6/16/23 01:57, Evan Quan wrote:
> > From: Mario Limonciello 
> >
> > 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 possible interference.
> >
> > To make WBRF feature functional, the kernel needs to be configured
> > with CONFIG_ACPI_WBRF and the platform is equipped with WBRF
> > support(from BIOS and drivers).
> >
> > Signed-off-by: Mario Limonciello 
> > Co-developed-by: Evan Quan 
> > Signed-off-by: Evan Quan 
> > --
> > v1->v2:
> >- place the new added member(`wbrf_supported`) in
> >  ieee80211_local(Johannes)
> >- handle chandefs change scenario properly(Johannes)
> >- some minor fixes around code sharing and possible invalid input
> >  checks(Johannes)
> > ---
> >   include/net/cfg80211.h |   8 +++
> >   net/mac80211/Makefile  |   2 +
> >   net/mac80211/chan.c|  11 +++
> >   net/mac80211/ieee80211_i.h |  19 +
> >   net/mac80211/main.c|   2 +
> >   net/mac80211/wbrf.c| 137
> +
> >   net/wireless/chan.c|   3 +-
> >   7 files changed, 181 insertions(+), 1 deletion(-)
> >   create mode 100644 net/mac80211/wbrf.c
> >
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index
> > 9e04f69712b1..c6dc337eafce 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
> >   cfg80211_chandef_compatible(const struct cfg80211_chan_def
> *chandef1,
> > const struct cfg80211_chan_def *chandef2);
> >
> > +/**
> > + * nl80211_chan_width_to_mhz - get the channel width in Mhz
> > + * @chan_width: the channel width from &enum nl80211_chan_width
> > + * Return: channel width in Mhz if the chan_width from &enum
> > +nl80211_chan_width
> > + * is valid. -1 otherwise.
> > + */
> > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width
> chan_width);
> > +
>
> It's up to mac80211 maintainers, but I would think that the changes to change
> nl80211_chan_width_to_mhz from static to exported should be separate
> from the patch to introduced WBRF support in the series.
Will do that.
>
> >   /**
> >* cfg80211_chandef_valid - check if a channel definition is valid
> >* @chandef: the channel definition to check diff --git
> > a/net/mac80211/Makefile b/net/mac80211/Makefile index
> > b8de44da1fb8..709eb678f42a 100644
> > --- a/net/mac80211/Makefile
> > +++ b/net/mac80211/Makefile
> > @@ -65,4 +65,6 @@ rc80211_minstrel-$(CONFIG_MAC80211_DEBUGFS)
> += \
> >
> >   mac80211-$(CONFIG_MAC80211_RC_MINSTREL) += $(rc80211_minstrel-
> y)
> >
> > +mac80211-$(CONFIG_ACPI_WBRF) += wbrf.o
> > +
> >   ccflags-y += -DDEBUG
> > diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c index
> > 77c90ed8f5d7..0c5289a9aa6c 100644
> > --- a/net/mac80211/chan.c
> > +++ b/net/mac80211/chan.c
> > @@ -506,11 +506,16 @@ static void _ieee80211_change_chanctx(struct
> > ieee80211_local *local,
> >
> > WARN_ON(!cfg80211_chandef_compatible(&ctx->conf.def,
> chandef));
> >
> > +   ieee80211_remove_wbrf(local, &ctx->conf.def);
> > +
> > ctx->conf.def = *chandef;
> >
> > /* check if min chanctx also changed */
> > changed = IEEE80211_CHANCTX_CHANGE_WIDTH |
> >   _ieee80211_recalc_chanctx_min_def(local, ctx, rsvd_for);
> > +
> > +   ieee80211_add_wbrf(local, &ctx->conf.def);
> > +
> > drv_change_chanctx(local, ctx, c

RE: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Johannes Berg 
> Sent: Monday, June 19, 2023 4:24 PM
> To: Limonciello, Mario ; Quan, Evan
> 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org; raf...@kernel.org; l...@kernel.org; Deucher,
> Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Lazar, Lijo 
> Subject: Re: [PATCH V3 2/7] wifi: mac80211: Add support for ACPI WBRF
>
> On Sun, 2023-06-18 at 21:17 -0500, Mario Limonciello wrote:
> >
> > > --- a/include/net/cfg80211.h
> > > +++ b/include/net/cfg80211.h
> > > @@ -920,6 +920,14 @@ const struct cfg80211_chan_def *
> > >   cfg80211_chandef_compatible(const struct cfg80211_chan_def
> *chandef1,
> > >   const struct cfg80211_chan_def *chandef2);
> > >
> > > +/**
> > > + * nl80211_chan_width_to_mhz - get the channel width in Mhz
> > > + * @chan_width: the channel width from &enum nl80211_chan_width
> > > + * Return: channel width in Mhz if the chan_width from &enum
> > > +nl80211_chan_width
> > > + * is valid. -1 otherwise.
> > > + */
> > > +int nl80211_chan_width_to_mhz(enum nl80211_chan_width
> chan_width);
> > > +
> >
> > It's up to mac80211 maintainers, but I would think that the changes to
> > change nl80211_chan_width_to_mhz from static to exported should be
> > separate from the patch to introduced WBRF support in the series.
>
> Yeah, that'd be nice :)
OK, I will move that into a new patch.
>
>
> > > +#define KHZ_TO_HZ(freq)  ((freq) * 1000ULL)
>
> Together with MHZ_TO_KHZ() for example :)
Sure.

Evan
>
> johannes

RE: [PATCH] drm/amd/pm: add abnormal fan detection for smu 13.0.0

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of
> Kenneth Feng
> Sent: Tuesday, June 20, 2023 11:46 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Feng, Kenneth 
> Subject: [PATCH] drm/amd/pm: add abnormal fan detection for smu 13.0.0
>
> add abnormal fan detection for smu 13.0.0
>
> Signed-off-by: Kenneth Feng 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index a6083957ae51..124287cbbff8 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -1710,6 +1710,7 @@ static int
> smu_v13_0_0_get_thermal_temperature_range(struct smu_context *smu,
>   range->mem_emergency_max = (pptable-
> >SkuTable.TemperatureLimit[TEMP_MEM] + CTF_OFFSET_MEM)*
>   SMU_TEMPERATURE_UNITS_PER_CENTIGRADES;
>   range->software_shutdown_temp = powerplay_table-
> >software_shutdown_temp;
> + range->software_shutdown_temp_offset = pptable-
> >SkuTable.FanAbnormalTempLimitOffset;
>
>   return 0;
>  }
> --
> 2.34.1

RE: [PATCH V3 4/7] drm/amd/pm: setup the framework to support Wifi RFI mitigation feature

[Quan, Evan]

[AMD Official Use Only - General]

> -Original Message-
> From: Lazar, Lijo 
> Sent: Monday, June 19, 2023 10:55 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Limonciello, Mario
> 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org
> Subject: Re: [PATCH V3 4/7] drm/amd/pm: setup the framework to support
> Wifi RFI mitigation feature
>
>
>
> On 6/16/2023 12:27 PM, Evan Quan wrote:
> > 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).
> >
> > To make WBRF feature functional, the kernel needs to be configured
> > with CONFIG_ACPI_WBRF and the platform is equipped with necessary ACPI
> > based mechanism to get amdgpu driver notified.
> >
> > Signed-off-by: Evan Quan 
> > ---
> >   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 | 184
> ++
> >   drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  20 ++
> >   drivers/gpu/drm/amd/pm/swsmu/smu_internal.h   |   3 +
> >   6 files changed, 315 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > index 02b827785e39..2f2ec64ed1b2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > @@ -50,6 +50,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >
> >   #include 
> >   #include 
> > @@ -241,6 +242,7 @@ extern int amdgpu_num_kcq;
> >   #define AMDGPU_VCNFW_LOG_SIZE (32 * 1024)
> >   extern int amdgpu_vcnfw_log;
> >   extern int amdgpu_sg_display;
> > +extern int amdgpu_wbrf;
> >
> >   #define AMDGPU_VM_MAX_NUM_CTX 4096
> >   #define AMDGPU_SG_THRESHOLD   (256*1024*1024)
> > @@ -741,6 +743,9 @@ struct amdgpu_reset_domain;
> >*/
> >   #define AMDGPU_HAS_VRAM(_adev) ((_adev)->gmc.real_vram_size)
> >
> > +typedef
> > +void (*wbrf_notify_handler) (struct amdgpu_device *adev);
> > +
> >   struct amdgpu_device {
> > struct device   *dev;
> > struct pci_dev  *pdev;
> > @@ -1050,6 +1055,8 @@ struct amdgpu_device {
> >
> > booljob_hang;
> > booldc_enabled;
> > +
> > +   wbrf_notify_handler wbrf_event_handler;
> >   };
> >
> >   static inline struct amdgpu_device *drm_to_adev(struct drm_device
> > *ddev) @@ -1381,6 +1388,25 @@ static inline int
> amdgpu_acpi_smart_shift_update(struct drm_device *dev,
> >  enum amdgpu_ss ss_state)
> { return 0; }
> >   #endif
> >
> > +#if defined(CONFIG_ACPI_WBRF)
> > +bool amdgpu_acpi_is_wbrf_supported(struct amdgpu_device *adev); int
> > +amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
> > +struct wbrf_ranges_out
> *exclusions_out); int
> > +amdgpu_acpi_register_wbrf_notify_handler(struct amdgpu_device *adev,
> > +wbrf_notify_handler handler); int
> > +amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device
> > +*adev); #else static inline bool amdgpu_acpi_is_wbrf_supported(struct
> > +amdgpu_device *adev) { return false; } static inline int
> > +amdgpu_acpi_wbrf_retrieve_exclusions(struct amdgpu_device *adev,
> > +struct wbrf_ranges_out
> *exclusions_out) { return 0; } static
> > +inline int amdgpu_acpi_register_wbrf_notify_handler(struct
> > +amdgpu_device *adev,
> > +wbrf_notify_handler handler)
> { return 0; } static inline
> > +int amdgpu_acpi_unregister_wbrf_notify_handler(struct amdgpu_device
> > +*adev) { return 0; } #endif
> > +
> >  

RE: [PATCH V2 2/7] wifi: mac80211: Add support for ACPI WBRF

[Quan, Evan]

[AMD Official Use Only - General]

Thanks Johannes. Comment in-line

> -Original Message-
> From: Johannes Berg 
> Sent: Friday, June 9, 2023 4:21 PM
> To: Quan, Evan ; raf...@kernel.org; l...@kernel.org;
> Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; kv...@kernel.org; n...@nbd.name;
> lore...@kernel.org; ryder@mediatek.com; shayne.c...@mediatek.com;
> sean.w...@mediatek.com; matthias@gmail.com;
> angelogioacchino.delre...@collabora.com; Limonciello, Mario
> ; Lazar, Lijo 
> Cc: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> wirel...@vger.kernel.org
> Subject: Re: [PATCH V2 2/7] wifi: mac80211: Add support for ACPI WBRF
>
> On Fri, 2023-06-09 at 15:28 +0800, Evan Quan wrote:
>
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -5551,6 +5551,10 @@ struct wiphy {
> >
> > u16 hw_timestamp_max_peers;
> >
> > +#ifdef CONFIG_ACPI_WBRF
> > +   bool wbrf_supported;
> > +#endif
>
> This should be in some private struct in mac80211, ieee80211_local I think.
There was indeed a proposal from Mario to put this in ieee80211_local.
But I thought "wbrf_supported" stands for a device specific feature and "struct 
wiphy" seemed the right place.
Anyway I can update this as suggested.
>
> > char priv[] __aligned(NETDEV_ALIGN);  };
> >
> > @@ -9067,4 +9071,18 @@ static inline int
> > cfg80211_color_change_notify(struct net_device *dev)  bool
> cfg80211_valid_disable_subchannel_bitmap(u16 *bitmap,
> >   const struct cfg80211_chan_def
> *chandef);
> >
> > +#ifdef CONFIG_ACPI_WBRF
> > +void ieee80211_check_wbrf_support(struct wiphy *wiphy); int
> > +ieee80211_add_wbrf(struct wiphy *wiphy,
> > +  struct cfg80211_chan_def *chandef); void
> > +ieee80211_remove_wbrf(struct wiphy *wiphy,
> > +  struct cfg80211_chan_def *chandef); #else static
> inline void
> > +ieee80211_check_wbrf_support(struct wiphy *wiphy) { } static inline
> > +int ieee80211_add_wbrf(struct wiphy *wiphy,
> > +struct cfg80211_chan_def *chandef)
> { return 0; } static
> > +inline void ieee80211_remove_wbrf(struct wiphy *wiphy,
> > +struct cfg80211_chan_def *chandef)
> { } #endif /*
> > +CONFIG_ACPI_WBRF */
>
> Same here, not the right place. This should even be in an internal
> mac80211 header (such as net/mac80211/ieee80211_i.h or create a new
> net/mac80211/wrbf.h or so if you prefer.)
Will update this altogether.
>
>
> > --- a/net/mac80211/chan.c
> > +++ b/net/mac80211/chan.c
> > @@ -668,6 +668,10 @@ static int ieee80211_add_chanctx(struct
> ieee80211_local *local,
> > lockdep_assert_held(&local->mtx);
> > lockdep_assert_held(&local->chanctx_mtx);
> >
> > +   err = ieee80211_add_wbrf(local->hw.wiphy, &ctx->conf.def);
> > +   if (err)
> > +   return err;
> > +
> > if (!local->use_chanctx)
> > local->hw.conf.radar_enabled = ctx->conf.radar_enabled;
> >
> > @@ -748,6 +752,8 @@ static void ieee80211_del_chanctx(struct
> ieee80211_local *local,
> > }
> >
> > ieee80211_recalc_idle(local);
> > +
> > +   ieee80211_remove_wbrf(local->hw.wiphy, &ctx->conf.def);
> >  }
> >
> >  static void ieee80211_free_chanctx(struct ieee80211_local *local,
> >
>
> This is tricky, and quite likely incorrect.
>
> First of all, chandefs can actually _change_, see _ieee80211_change_chanctx().
> You'd probably have to call this add/remove (or have modify) whenever we
> call drv_change_chanctx() to change the width (not if radar/rx chains change).
Thanks for pointing this out. Unfortunately I have limit knowledge about 
network related.
Can you help me to list all those APIs? Any others except the four below?
_ieee80211_change_chanctx
ieee80211_recalc_chanctx_min_def  (Just curious why "!local->use_chanctx" is 
not cover in this API like others?)
ieee80211_recalc_radar_chanctx  (do you mean this one can be ignored ?)
ieee80211_recalc_smps_chanctx
>
> Secondly, you don't know if the driver will actually use ctx->conf.def, or 
> ctx-
> >conf.mindef. For client mode that doesn't matter, but for AP mode if the AP 
> >is
> configured to say 160 MHz, it might actually configure down to 20 MHz when
> no stations are connected (or only 20 MHz stations are). I don't know if you
> really care abou

RE: [PATCH v2] drm/amdgpu: Fix memcpy() in sienna_cichlid_append_powerplay_table function.

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: SHANMUGAM, SRINIVASAN 
> Sent: Friday, June 9, 2023 4:45 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Quan, Evan ; Gui, Jack
> 
> Cc: amd-gfx@lists.freedesktop.org; SHANMUGAM, SRINIVASAN
> 
> Subject: [PATCH v2] drm/amdgpu: Fix memcpy() in
> sienna_cichlid_append_powerplay_table function.
>
> Fixes the following gcc with W=1:
>
> In file included from ./include/linux/string.h:253,
>  from ./include/linux/bitmap.h:11,
>  from ./include/linux/cpumask.h:12,
>  from ./arch/x86/include/asm/cpumask.h:5,
>  from ./arch/x86/include/asm/msr.h:11,
>  from ./arch/x86/include/asm/processor.h:22,
>  from ./arch/x86/include/asm/cpufeature.h:5,
>  from ./arch/x86/include/asm/thread_info.h:53,
>  from ./include/linux/thread_info.h:60,
>  from ./arch/x86/include/asm/preempt.h:7,
>  from ./include/linux/preempt.h:78,
>  from ./include/linux/spinlock.h:56,
>  from ./include/linux/mmzone.h:8,
>  from ./include/linux/gfp.h:7,
>  from ./include/linux/firmware.h:7,
>  from
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:2
> 6:
> In function ‘fortify_memcpy_chk’,
> inlined from ‘sienna_cichlid_append_powerplay_table’ at
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:4
> 44:2,
> inlined from ‘sienna_cichlid_setup_pptable’ at
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:5
> 06:8,
> inlined from ‘sienna_cichlid_setup_pptable’ at
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/sienna_cichlid_ppt.c:4
> 94:12:
> ./include/linux/fortify-string.h:413:4: warning: call to
> ‘__read_overflow2_field’ declared with attribute warning: detected read
> beyond size of field (2nd parameter); maybe use struct_group()? [-
> Wattribute-warning]
>   413 |__read_overflow2_field(q_size_field, size);
>   |^~
> ^~
>
> the compiler complains about the size calculation in the memcpy() -
> "sizeof(*smc_dpm_table) - sizeof(smc_dpm_table->table_header)" is much
> larger than what fits into table_member.
>
> 'Fixes: 7077b19a38240 ("drm/amd/pm: use macro to get pptable members")'
> Suggested-by: Evan Quan 
> Cc: Evan Quan 
> Cc: Chengming Gui 
> Cc: Christian König 
> Cc: Alex Deucher 
> Signed-off-by: Srinivasan Shanmugam 
> ---
>
> v2:
>  - turned to the way used for nv1x (Evan)
>
>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c| 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index 85d53597eb07..f7ed3e655e39 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -431,7 +431,13 @@ static int
> sienna_cichlid_append_powerplay_table(struct smu_context *smu)  {
>   struct atom_smc_dpm_info_v4_9 *smc_dpm_table;
>   int index, ret;
> - I2cControllerConfig_t *table_member;
> + PPTable_beige_goby_t *ppt_beige_goby;
> + PPTable_t *ppt;
> +
> + if (smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0,
> 13))
> + ppt_beige_goby = smu->smu_table.driver_pptable;
> + else
> + ppt = smu->smu_table.driver_pptable;
>
>   index =
> get_index_into_master_table(atom_master_list_of_data_tables_v2_1,
>   smc_dpm_info);
> @@ -440,9 +446,13 @@ static int
> sienna_cichlid_append_powerplay_table(struct smu_context *smu)
> (uint8_t **)&smc_dpm_table);
>   if (ret)
>   return ret;
> - GET_PPTABLE_MEMBER(I2cControllers, &table_member);
> - memcpy(table_member, smc_dpm_table->I2cControllers,
> - sizeof(*smc_dpm_table) - sizeof(smc_dpm_table-
> >table_header));
> +
> + if (smu->adev->ip_versions[MP1_HWIP][0] == IP_VERSION(11, 0,
> 13))
> + smu_memcpy_trailing(ppt_beige_goby, I2cControllers,
> BoardReserved,
> + smc_dpm_table, I2cControllers);
> + else
> + smu_memcpy_trailing(ppt, I2cControllers, BoardReserved,
> + smc_dpm_table, I2cControllers);
>
>   return 0;
>  }
> --
> 2.25.1

RE: [PATCH] drm/amd/pm: Fix memory some memory corruption

[Quan, Evan]

[AMD Official Use Only - General]

Thanks for catching this.
Reviewed-by: Evan Quan 

> -Original Message-
> From: Dan Carpenter 
> Sent: Tuesday, June 6, 2023 4:34 PM
> To: Quan, Evan 
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; Lazar, Lijo
> ; Zhang, Hawking ; Feng,
> Kenneth ; Li, Candice ;
> Chai, Thomas ; Wang, Yang(Kevin)
> ; Zhang, Horatio ;
> amd-gfx@lists.freedesktop.org; kernel-janit...@vger.kernel.org
> Subject: [PATCH] drm/amd/pm: Fix memory some memory corruption
>
> The "od_table" is a pointer to a large struct, but this code is doing pointer
> math as if it were pointing to bytes.  It results in writing far outside the 
> struct.
>
> Fixes: f0a0c659fb96 ("drm/amd/pm: fulfill the OD support for SMU13.0.0")
> Fixes: e3afa4f988b3 ("drm/amd/pm: fulfill the OD support for SMU13.0.7")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 4 ++--
> drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index 5ac5ea770c1c..413e592f0ed6 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -1535,7 +1535,7 @@ static int smu_v13_0_0_od_edit_dpm_table(struct
> smu_context *smu,
>* settings. Thus we do not cache it.
>*/
>   offset_of_featurectrlmask = offsetof(OverDriveTable_t,
> FeatureCtrlMask);
> - if (memcmp(od_table + offset_of_featurectrlmask,
> + if (memcmp((u8 *)od_table + offset_of_featurectrlmask,
>  table_context->user_overdrive_table +
> offset_of_featurectrlmask,
>  sizeof(OverDriveTableExternal_t) -
> offset_of_featurectrlmask)) {
>   smu_v13_0_0_dump_od_table(smu, od_table); @@ -
> 1548,7 +1548,7 @@ static int smu_v13_0_0_od_edit_dpm_table(struct
> smu_context *smu,
>
>   od_table->OverDriveTable.FeatureCtrlMask = 0;
>   memcpy(table_context->user_overdrive_table +
> offset_of_featurectrlmask,
> -od_table + offset_of_featurectrlmask,
> +(u8 *)od_table + offset_of_featurectrlmask,
>  sizeof(OverDriveTableExternal_t) -
> offset_of_featurectrlmask);
>
>   if (!memcmp(table_context->user_overdrive_table,
> 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 0bd086360efa..cda4e818aab7 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
> @@ -1524,7 +1524,7 @@ static int smu_v13_0_7_od_edit_dpm_table(struct
> smu_context *smu,
>* settings. Thus we do not cache it.
>*/
>   offset_of_featurectrlmask = offsetof(OverDriveTable_t,
> FeatureCtrlMask);
> - if (memcmp(od_table + offset_of_featurectrlmask,
> + if (memcmp((u8 *)od_table + offset_of_featurectrlmask,
>  table_context->user_overdrive_table +
> offset_of_featurectrlmask,
>  sizeof(OverDriveTableExternal_t) -
> offset_of_featurectrlmask)) {
>   smu_v13_0_7_dump_od_table(smu, od_table); @@ -
> 1537,7 +1537,7 @@ static int smu_v13_0_7_od_edit_dpm_table(struct
> smu_context *smu,
>
>   od_table->OverDriveTable.FeatureCtrlMask = 0;
>   memcpy(table_context->user_overdrive_table +
> offset_of_featurectrlmask,
> -od_table + offset_of_featurectrlmask,
> +(u8 *)od_table + offset_of_featurectrlmask,
>  sizeof(OverDriveTableExternal_t) -
> offset_of_featurectrlmask);
>
>   if (!memcmp(table_context->user_overdrive_table,
> --
> 2.39.2

RE: [PATCH] drm/amd/pm: conditionally disable pcie lane switching for some sienna_cichlid SKUs

[Quan, Evan]

[AMD Official Use Only - General]

Hi Alex,

Can we land this as a temporary solution while we are seeking a more proper one?
This is gating our customer and I was pushed for a solution.

BR,
Evan
> -Original Message-
> From: Quan, Evan
> Sent: Friday, April 21, 2023 3:32 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Limonciello, Mario
> 
> Subject: RE: [PATCH] drm/amd/pm: conditionally disable pcie lane switching
> for some sienna_cichlid SKUs
>
> [AMD Official Use Only - General]
>
> This seems able to address some audio noise issue observed per customer's
> feedback.
>
> Evan
> > -Original Message-
> > From: Quan, Evan 
> > Sent: Friday, April 21, 2023 3:29 PM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander ; Limonciello, Mario
> > ; Quan, Evan 
> > Subject: [PATCH] drm/amd/pm: conditionally disable pcie lane switching
> > for some sienna_cichlid SKUs
> >
> > Disable the pcie lane switching for some sienna_cichlid SKUs since it
> > might not work well on some platforms.
> >
> > Signed-off-by: Evan Quan 
> > Change-Id: Iea9ceaa146c8706768ee077c10e5d33bce9bc1c2
> > ---
> >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 92 +++-
> --
> > -
> >  1 file changed, 74 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > index 4b91cdc3eaa0..e7223513e384 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > @@ -2067,33 +2067,94 @@ static int
> > sienna_cichlid_display_disable_memory_clock_switch(struct smu_context
> > return ret;
> >  }
> >
> > +static void sienna_cichlid_get_override_pcie_settings(struct
> > +smu_context
> > *smu,
> > + uint32_t
> > *gen_speed_override,
> > + uint32_t
> > *lane_width_override)
> > +{
> > +   struct amdgpu_device *adev = smu->adev;
> > +
> > +   *gen_speed_override = 0xff;
> > +   *lane_width_override = 0xff;
> > +
> > +   switch (adev->pdev->device) {
> > +   case 0x73A0:
> > +   case 0x73A1:
> > +   case 0x73A2:
> > +   case 0x73A3:
> > +   case 0x73AB:
> > +   case 0x73AE:
> > +   /* Bit 7:0: PCIE lane width, 1 to 7 corresponds is x1 to x32 */
> > +   *lane_width_override = 6;
> > +   break;
> > +   case 0x73E0:
> > +   case 0x73E1:
> > +   case 0x73E3:
> > +   *lane_width_override = 4;
> > +   break;
> > +   case 0x7420:
> > +   case 0x7421:
> > +   case 0x7422:
> > +   case 0x7423:
> > +   case 0x7424:
> > +   *lane_width_override = 3;
> > +   break;
> > +   default:
> > +   break;
> > +   }
> > +}
> > +
> > +#define MAX(a, b)  ((a) > (b) ? (a) : (b))
> > +
> >  static int sienna_cichlid_update_pcie_parameters(struct smu_context *smu,
> >  uint32_t pcie_gen_cap,
> >  uint32_t pcie_width_cap)
> >  {
> > struct smu_11_0_dpm_context *dpm_context = smu-
> > >smu_dpm.dpm_context;
> > -
> > -   uint32_t smu_pcie_arg;
> > +   struct smu_11_0_pcie_table *pcie_table = &dpm_context-
> > >dpm_tables.pcie_table;
> > +   uint32_t gen_speed_override, lane_width_override;
> > uint8_t *table_member1, *table_member2;
> > +   uint32_t min_gen_speed, max_gen_speed;
> > +   uint32_t min_lane_width, max_lane_width;
> > +   uint32_t smu_pcie_arg;
> > int ret, i;
> >
> > GET_PPTABLE_MEMBER(PcieGenSpeed, &table_member1);
> > GET_PPTABLE_MEMBER(PcieLaneCount, &table_member2);
> >
> > -   /* lclk dpm table setup */
> > -   for (i = 0; i < MAX_PCIE_CONF; i++) {
> > -   dpm_context->dpm_tables.pcie_table.pcie_gen[i] =
> > table_member1[i];
> > -   dpm_context->dpm_tables.pcie_table.pcie_lane[i] =
> > table_member2[i];
> > +   sienna_cichlid_get_override_pcie_settings(smu,
> > + &gen_speed_override,
> > + &lane_width_override);
> > +
> > +   /* PCIE gen speed override */
> > +   if (gen_speed_override != 0xff) {
> > +   min_gen_speed = MIN(pcie_gen

RE: [PATCH] drm/amd/pm: add missing NotifyPowerSource message mapping for SMU13.0.7

[Quan, Evan]

[Public]

> -Original Message-
> From: Chen, Guchun 
> Sent: Friday, May 19, 2023 8:04 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: RE: [PATCH] drm/amd/pm: add missing NotifyPowerSource message
> mapping for SMU13.0.7
>
> [Public]
>
> Looks it's better to add a Fixes tag like Fixes: 4dd9b5392c57 ("drm/amd/pm:
> fix possible power mode mismatch between driver and PMFW"), if I
> understand it correctly.
Yes, will add that in V2.

Evan
>
> Regards,
> Guchun
>
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Evan Quan
> > Sent: Friday, May 19, 2023 3:53 PM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander ; Quan, Evan
> > 
> > Subject: [PATCH] drm/amd/pm: add missing NotifyPowerSource message
> > mapping for SMU13.0.7
> >
> > Otherwise, the power source switching will fail due to message unavailable.
> >
> > Signed-off-by: Evan Quan 
> > ---
> >  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > 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 1b6116cf8b4c..cf6827179fd1 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
> > @@ -125,6 +125,7 @@ static struct cmn2asic_msg_mapping
> > smu_v13_0_7_message_map[SMU_MSG_MAX_COUNT] =
> >   MSG_MAP(ArmD3,  PPSMC_MSG_ArmD3,
> > 0),
> >   MSG_MAP(AllowGpo,   PPSMC_MSG_SetGpoAllow,
> > 0),
> >   MSG_MAP(GetPptLimit,
> >   PPSMC_MSG_GetPptLimit, 0),
> > + MSG_MAP(NotifyPowerSource,
> >   PPSMC_MSG_NotifyPowerSource,   0),
> >  };
> >
> >  static struct cmn2asic_mapping smu_v13_0_7_clk_map[SMU_CLK_COUNT]
> = {
> > --
> > 2.34.1
>

RE: [PATCH v4] drm/amd: Flush any delayed gfxoff on suspend entry

[Quan, Evan]

[AMD Official Use Only - General]

If I understand correctly, similar job is already performed in 
"amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);"
Maybe you just need to undo the "skip PG for GFX on S0ix"?

/* skip PG for GFX, SDMA on S0ix */
if (adev->in_s0ix &&
(adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_GFX 
||
 adev->ip_blocks[i].version->type == 
AMD_IP_BLOCK_TYPE_SDMA))
continue;

Evan
> -Original Message-
> From: amd-gfx  On Behalf Of Mario
> Limonciello
> Sent: Friday, May 19, 2023 12:53 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Tsao, Anson ; Huang, Tim
> ; Martinez, Juan ;
> Limonciello, Mario ; Gong, Richard
> 
> Subject: [PATCH v4] drm/amd: Flush any delayed gfxoff on suspend entry
>
> DCN 3.1.4 is reported to hang on s2idle entry if graphics activity
> is happening during entry.  This is because GFXOFF was scheduled as
> delayed but RLC gets disabled in s2idle entry sequence which will
> hang GFX IP if not already in GFXOFF.
>
> To help this problem, flush any delayed work for GFXOFF early in
> s2idle entry sequence to ensure that it's off when RLC is changed.
>
> commit 3964b0c2e843 ("drm/amdgpu: complete gfxoff allow signal during
> suspend without delay") modified power gating flow so that if called
> in s0ix that it ensured that GFXOFF wasn't put in work queue but
> instead processed immediately.
>
> This is dead code due to commit 5d70a549d00d ("drm/amdgpu: skip
> CG/PG for gfx during S0ix") because GFXOFF will now not be explicitly
> called as part of the suspend entry code.  Remove that dead code.
>
> Cc: sta...@vger.kernel.org # 6.1+
> Suggested-by: Tim Huang 
> Signed-off-by: Mario Limonciello 
> ---
> v3->v4:
>  * Drop patches 2-4
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c| 9 +
>  2 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a9d9bbe8586b..059139f1f973 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4316,6 +4316,7 @@ int amdgpu_device_suspend(struct drm_device
> *dev, bool fbcon)
>   drm_fb_helper_set_suspend_unlocked(adev_to_drm(adev)-
> >fb_helper, true);
>
>   cancel_delayed_work_sync(&adev->delayed_init_work);
> + flush_delayed_work(&adev->gfx.gfx_off_delay_work);
>
>   amdgpu_ras_suspend(adev);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> index f2d0b1d55d77..b1190eb0e9c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
> @@ -692,15 +692,8 @@ void amdgpu_gfx_off_ctrl(struct amdgpu_device
> *adev, bool enable)
>
>   if (adev->gfx.gfx_off_req_count == 0 &&
>   !adev->gfx.gfx_off_state) {
> - /* If going to s2idle, no need to wait */
> - if (adev->in_s0ix) {
> - if
> (!amdgpu_dpm_set_powergating_by_smu(adev,
> - AMD_IP_BLOCK_TYPE_GFX,
> true))
> - adev->gfx.gfx_off_state = true;
> - } else {
> - schedule_delayed_work(&adev-
> >gfx.gfx_off_delay_work,
> + schedule_delayed_work(&adev-
> >gfx.gfx_off_delay_work,
> delay);
> - }
>   }
>   } else {
>   if (adev->gfx.gfx_off_req_count == 0) {
> --
> 2.34.1

RE: [PATCH] drm/amd/pm: Fix output of pp_od_clk_voltage

[Quan, Evan]

[AMD Official Use Only - General]

Sorry for missing this.
The patch seems fine to me.  Reviewed-by: Evan Quan 

Evan
> -Original Message-
> From: Jonatas Esteves 
> Sent: Tuesday, November 15, 2022 10:33 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amd/pm: Fix output of pp_od_clk_voltage
>
> >
> > [AMD Official Use Only - General]
> >
> >
> >
> > > -Original Message-
> > > From: amd-gfx  On Behalf Of
> > > Jonatas Esteves
> > > Sent: Tuesday, November 15, 2022 7:13 AM
> > > To: amd-gfx@lists.freedesktop.org
> > > Cc: Jonatas Esteves 
> > > Subject: [PATCH] drm/amd/pm: Fix output of pp_od_clk_voltage
> > >
> > > Printing the other clock types should not be conditioned on being
> > > able to print OD_SCLK. Some GPUs currently have limited capability
> > > of only printing a subset of these.
> > >
> > > Since this condition was introduced in v5.18-rc1, reading from
> > > `pp_od_clk_voltage` has been returning empty on the Asus ROG Strix
> > > G15 (2021).
> > What's the output then with this patch applied?
> ```
> $ cat /sys/class/drm/card1/device/pp_od_clk_voltage
> OD_VDDGFX_OFFSET:
> 0mV
> OD_RANGE:
> ```
>
> Changing OD_VDDGFX_OFFSET works for this chip. Changing GFXCLK_LIMITS
> and UCLK_LIMITS is not supported as per the checks in sienna_cichlid_ppt.c ->
> sienna_cichlid_od_edit_dpm_table()
>
> > Meanwhile can you show me the 'lspci' output( I wonder which asic is used
> on your system)?
> The ASIC is a RX 6800M / NAVI22 / Navy Flounder / IP_VERSION(11, 0, 11)
>
> ```
> $ lspci
> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne
> Root Complex
> 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne
> IOMMU
> 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy
> Host Bridge
> 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP
> Bridge
> 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy
> Host Bridge
> 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe
> GPP Bridge
> 00:02.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe
> GPP Bridge
> 00:02.4 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe
> GPP Bridge
> 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy
> Host Bridge
> 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe
> GPP Bridge to Bus
> 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller
> (rev 51)
> 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev
> 51)
> 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 0
> 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 1
> 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 2
> 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 3
> 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 4
> 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 5
> 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 6
> 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data
> Fabric; Function 7
> 01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
> Upstream Port of PCI Express Switch (rev c3)
> 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL
> Downstream Port of PCI Express Switch
> 03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22
> [Radeon RX 6700/6700 XT/6750 XT / 6800M] (rev c3)
> 03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi
> 21/23 HDMI/DP Audio Controller
> 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
> 05:00.0 Network controller: MEDIATEK Corp. MT7921 802.11ax PCI Express
> Wireless Network Adapter
> 06:00.0 Non-Volatile memory controller: Intel Corporation Device f1aa (rev
> 03)
> 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
> [AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c4)
> 07:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Renoir Radeon
> High Definition Audio Controller
> 07:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family
> 17h (Models 10h-1fh) Platform Security Processor
> 07:00.3 USB controller: Advanced Micro Devices, Inc

RE: [PATCH] drm/amd/pm: avoid potential UBSAN issue on legacy asics

[Quan, Evan]

[AMD Official Use Only - General]

Acked-by: Evan Quan 

> -Original Message-
> From: Chen, Guchun 
> Sent: Tuesday, May 9, 2023 9:43 AM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Zhang, Hawking
> ; Lazar, Lijo ; Quan, Evan
> 
> Cc: Chen, Guchun 
> Subject: [PATCH] drm/amd/pm: avoid potential UBSAN issue on legacy asics
> 
> Prevent further casting on chip MULLINS/KABINI/KAVERI when calling
> amdgpu_dpm_is_overdrive_supported, this can avoid UBSAN complain
> in init sequence.
> 
> Suggested-by: Evan Quan 
> Signed-off-by: Guchun Chen 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> index 86246f69dbe1..ccd3ea89eacf 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> @@ -1467,8 +1467,14 @@ int amdgpu_dpm_is_overdrive_supported(struct
> amdgpu_device *adev)
>   } else {
>   struct pp_hwmgr *hwmgr;
> 
> - /* SI asic does not carry od_enabled */
> - if (adev->family == AMDGPU_FAMILY_SI)
> + /*
> +  * SI asic and chip MULLINS/KABINI/KAVERI do not carry
> +  * od_enabled, as its pp_handle is casted from adev.
> +  */
> + if ((adev->family == AMDGPU_FAMILY_SI) ||
> + (adev->asic_type == CHIP_MULLINS) ||
> + (adev->asic_type == CHIP_KABINI) ||
> + (adev->asic_type == CHIP_KAVERI))
>   return false;
> 
>   hwmgr = (struct pp_hwmgr *)adev->powerplay.pp_handle;
> --
> 2.25.1

RE: [PATCH] drm/amd/pm: parse pp_handle under appropriate conditions

[Quan, Evan]

[AMD Official Use Only - General]

+Mario

I believe the comment below from Mario points the right direction to suppress 
the "UBSAN: invalid-load..." warnings.
https://gitlab.freedesktop.org/drm/amd/-/issues/2541#note_1898035
However, it might be not right to simply drop the line below since the 
adev->powerplay.pp_handle pointer is still needed for those APIs like 
amdgpu_dpm_read_sensor().
- adev->powerplay.pp_handle = adev;

BR
Evan
> -Original Message-
> From: Chen, Guchun 
> Sent: Friday, May 5, 2023 4:24 PM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> ; Zhang, Hawking
> ; Lazar, Lijo ; Quan, Evan
> ; Koenig, Christian ;
> Pan, Xinhui 
> Cc: Chen, Guchun 
> Subject: [PATCH] drm/amd/pm: parse pp_handle under appropriate
> conditions
> 
> amdgpu_dpm_is_overdrive_supported is a common API across all
> asics, so we should cast pp_handle into correct structure
> under different power frameworks.
> 
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2541
> Fixes: ebfc253335af("drm/amd/pm: do not expose the smu_context
> structure used internally in power")
> Signed-off-by: Guchun Chen 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_dpm.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> index f0068df2d073..ae45abeab5b5 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> @@ -1455,13 +1455,15 @@ int
> amdgpu_dpm_get_smu_prv_buf_details(struct amdgpu_device *adev,
> 
>  int amdgpu_dpm_is_overdrive_supported(struct amdgpu_device *adev)
>  {
> - struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;
> - struct smu_context *smu = adev->powerplay.pp_handle;
> -
> - if ((is_support_sw_smu(adev) && smu->od_enabled) ||
> - (is_support_sw_smu(adev) && smu->is_apu) ||
> - (!is_support_sw_smu(adev) && hwmgr->od_enabled))
> - return true;
> + if (is_support_sw_smu(adev)) {
> + struct smu_context *smu = adev->powerplay.pp_handle;
> + if (smu->od_enabled || smu->is_apu)
> + return true;
> + } else {
> + struct pp_hwmgr *hwmgr = adev->powerplay.pp_handle;
> + if (hwmgr->od_enabled)
> + return true;
> + }
> 
>   return false;
>  }
> --
> 2.25.1

RE: [PATCH] drm/amd/pm: conditionally disable pcie lane switching for some sienna_cichlid SKUs

[Quan, Evan]

[Public]



> -Original Message-
> From: Limonciello, Mario 
> Sent: Friday, April 21, 2023 9:40 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: RE: [PATCH] drm/amd/pm: conditionally disable pcie lane switching
> for some sienna_cichlid SKUs
> 
> [Public]
> 
> 
> 
> > -Original Message-
> > From: Quan, Evan 
> > Sent: Friday, April 21, 2023 02:29
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander ; Limonciello,
> Mario
> > ; Quan, Evan 
> > Subject: [PATCH] drm/amd/pm: conditionally disable pcie lane switching
> > for some sienna_cichlid SKUs
> >
> > Disable the pcie lane switching for some sienna_cichlid SKUs since it
> > might not work well on some platforms.
> >
> > Signed-off-by: Evan Quan 
> > Change-Id: Iea9ceaa146c8706768ee077c10e5d33bce9bc1c2
> 
> You can drop the Gerrit Change-Id here
Sure, thanks.

Evan
> 
> > ---
> >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 92
> +++
> >  1 file changed, 74 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > index 4b91cdc3eaa0..e7223513e384 100644
> > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > @@ -2067,33 +2067,94 @@ static int
> > sienna_cichlid_display_disable_memory_clock_switch(struct smu_context
> > return ret;
> >  }
> >
> > +static void sienna_cichlid_get_override_pcie_settings(struct
> > +smu_context
> > *smu,
> > + uint32_t
> > *gen_speed_override,
> > + uint32_t
> > *lane_width_override)
> > +{
> > +   struct amdgpu_device *adev = smu->adev;
> > +
> > +   *gen_speed_override = 0xff;
> > +   *lane_width_override = 0xff;
> > +
> > +   switch (adev->pdev->device) {
> > +   case 0x73A0:
> > +   case 0x73A1:
> > +   case 0x73A2:
> > +   case 0x73A3:
> > +   case 0x73AB:
> > +   case 0x73AE:
> > +   /* Bit 7:0: PCIE lane width, 1 to 7 corresponds is x1 to x32 */
> > +   *lane_width_override = 6;
> > +   break;
> > +   case 0x73E0:
> > +   case 0x73E1:
> > +   case 0x73E3:
> > +   *lane_width_override = 4;
> > +   break;
> > +   case 0x7420:
> > +   case 0x7421:
> > +   case 0x7422:
> > +   case 0x7423:
> > +   case 0x7424:
> > +   *lane_width_override = 3;
> > +   break;
> > +   default:
> > +   break;
> > +   }
> > +}
> > +
> > +#define MAX(a, b)  ((a) > (b) ? (a) : (b))
> > +
> >  static int sienna_cichlid_update_pcie_parameters(struct smu_context
> *smu,
> >  uint32_t pcie_gen_cap,
> >  uint32_t pcie_width_cap)
> >  {
> > struct smu_11_0_dpm_context *dpm_context = smu-
> > >smu_dpm.dpm_context;
> > -
> > -   uint32_t smu_pcie_arg;
> > +   struct smu_11_0_pcie_table *pcie_table = &dpm_context-
> > >dpm_tables.pcie_table;
> > +   uint32_t gen_speed_override, lane_width_override;
> > uint8_t *table_member1, *table_member2;
> > +   uint32_t min_gen_speed, max_gen_speed;
> > +   uint32_t min_lane_width, max_lane_width;
> > +   uint32_t smu_pcie_arg;
> > int ret, i;
> >
> > GET_PPTABLE_MEMBER(PcieGenSpeed, &table_member1);
> > GET_PPTABLE_MEMBER(PcieLaneCount, &table_member2);
> >
> > -   /* lclk dpm table setup */
> > -   for (i = 0; i < MAX_PCIE_CONF; i++) {
> > -   dpm_context->dpm_tables.pcie_table.pcie_gen[i] =
> > table_member1[i];
> > -   dpm_context->dpm_tables.pcie_table.pcie_lane[i] =
> > table_member2[i];
> > +   sienna_cichlid_get_override_pcie_settings(smu,
> > + &gen_speed_override,
> > + &lane_width_override);
> > +
> > +   /* PCIE gen speed override */
> > +   if (gen_speed_override != 0xff) {
> > +   min_gen_speed = MIN(pcie_gen_cap, gen_speed_override);
> > +   max_gen_speed = MIN(pcie_gen_cap,
> gen_speed_override);
> > +   } else {
> > +   min_gen_speed = MAX(0, table_member1[0]);
> > +   

RE: [PATCH] drm/amd/pm: conditionally disable pcie lane switching for some sienna_cichlid SKUs

[Quan, Evan]

[AMD Official Use Only - General]

This seems able to address some audio noise issue observed per customer's 
feedback.

Evan
> -Original Message-
> From: Quan, Evan 
> Sent: Friday, April 21, 2023 3:29 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Limonciello, Mario
> ; Quan, Evan 
> Subject: [PATCH] drm/amd/pm: conditionally disable pcie lane switching for
> some sienna_cichlid SKUs
> 
> Disable the pcie lane switching for some sienna_cichlid SKUs since it
> might not work well on some platforms.
> 
> Signed-off-by: Evan Quan 
> Change-Id: Iea9ceaa146c8706768ee077c10e5d33bce9bc1c2
> ---
>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 92 +++---
> -
>  1 file changed, 74 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index 4b91cdc3eaa0..e7223513e384 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -2067,33 +2067,94 @@ static int
> sienna_cichlid_display_disable_memory_clock_switch(struct smu_context
>   return ret;
>  }
> 
> +static void sienna_cichlid_get_override_pcie_settings(struct smu_context
> *smu,
> +   uint32_t
> *gen_speed_override,
> +   uint32_t
> *lane_width_override)
> +{
> + struct amdgpu_device *adev = smu->adev;
> +
> + *gen_speed_override = 0xff;
> + *lane_width_override = 0xff;
> +
> + switch (adev->pdev->device) {
> + case 0x73A0:
> + case 0x73A1:
> + case 0x73A2:
> + case 0x73A3:
> + case 0x73AB:
> + case 0x73AE:
> + /* Bit 7:0: PCIE lane width, 1 to 7 corresponds is x1 to x32 */
> + *lane_width_override = 6;
> + break;
> + case 0x73E0:
> + case 0x73E1:
> + case 0x73E3:
> + *lane_width_override = 4;
> + break;
> + case 0x7420:
> + case 0x7421:
> + case 0x7422:
> + case 0x7423:
> + case 0x7424:
> + *lane_width_override = 3;
> + break;
> + default:
> + break;
> + }
> +}
> +
> +#define MAX(a, b)((a) > (b) ? (a) : (b))
> +
>  static int sienna_cichlid_update_pcie_parameters(struct smu_context *smu,
>uint32_t pcie_gen_cap,
>uint32_t pcie_width_cap)
>  {
>   struct smu_11_0_dpm_context *dpm_context = smu-
> >smu_dpm.dpm_context;
> -
> - uint32_t smu_pcie_arg;
> + struct smu_11_0_pcie_table *pcie_table = &dpm_context-
> >dpm_tables.pcie_table;
> + uint32_t gen_speed_override, lane_width_override;
>   uint8_t *table_member1, *table_member2;
> + uint32_t min_gen_speed, max_gen_speed;
> + uint32_t min_lane_width, max_lane_width;
> + uint32_t smu_pcie_arg;
>   int ret, i;
> 
>   GET_PPTABLE_MEMBER(PcieGenSpeed, &table_member1);
>   GET_PPTABLE_MEMBER(PcieLaneCount, &table_member2);
> 
> - /* lclk dpm table setup */
> - for (i = 0; i < MAX_PCIE_CONF; i++) {
> - dpm_context->dpm_tables.pcie_table.pcie_gen[i] =
> table_member1[i];
> - dpm_context->dpm_tables.pcie_table.pcie_lane[i] =
> table_member2[i];
> + sienna_cichlid_get_override_pcie_settings(smu,
> +   &gen_speed_override,
> +   &lane_width_override);
> +
> + /* PCIE gen speed override */
> + if (gen_speed_override != 0xff) {
> + min_gen_speed = MIN(pcie_gen_cap, gen_speed_override);
> + max_gen_speed = MIN(pcie_gen_cap,
> gen_speed_override);
> + } else {
> + min_gen_speed = MAX(0, table_member1[0]);
> + max_gen_speed = MIN(pcie_gen_cap, table_member1[1]);
> + min_gen_speed = min_gen_speed > max_gen_speed ?
> + max_gen_speed : min_gen_speed;
>   }
> + pcie_table->pcie_gen[0] = min_gen_speed;
> + pcie_table->pcie_gen[1] = max_gen_speed;
> +
> + /* PCIE lane width override */
> + if (lane_width_override != 0xff) {
> + min_lane_width = MIN(pcie_width_cap,
> lane_width_override);
> + max_lane_width = MIN(pcie_width_cap,
> lane_width_override);
> + } else {
> + min_lane_width = MAX(1, table_member2[0]);
> + max_lane_width = MIN(pcie_width_cap, table_member2[1]);
> +

RE: drm/amdgpu/gfx9: switch to golden tsc registers for raven/raven2

[Quan, Evan]

[AMD Official Use Only - General]

Better to update the patch title with prefix as "drm/amdgpu:" instead of 
"drm/amdgpu/gfx9:".
Either way, the patch is Reviewed-by: Evan Quan 

Evan
From: Zhang, Jesse(Jie) 
Sent: Wednesday, April 12, 2023 9:24 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander 
; Quan, Evan ; Zhang, Yifan 

Subject: drm/amdgpu/gfx9: switch to golden tsc registers for raven/raven2


[AMD Official Use Only - General]

  Due to raven/raven2 maybe enable  sclk slow down,
they cannot get clock count by the RLC at the auto level of dpm performance.
So switch to golden tsc register.

Signed-off-by: Jesse Zhang mailto:jesse.zh...@amd.com>>
Signed-off-by: Evan Quan mailto:evan.q...@amd.com>>

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index ae09fc1cfe6b..c99d9e642e51 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -149,6 +149,16 @@ MODULE_FIRMWARE("amdgpu/aldebaran_sjt_mec2.bin");
#define mmGOLDEN_TSC_COUNT_LOWER_Renoir0x0026
#define mmGOLDEN_TSC_COUNT_LOWER_Renoir_BASE_IDX   1

+#define mmGOLDEN_TSC_COUNT_UPPER_Raven   0x007a
+#define mmGOLDEN_TSC_COUNT_UPPER_Raven_BASE_IDX 0
+#define mmGOLDEN_TSC_COUNT_LOWER_Raven   0x007b
+#define mmGOLDEN_TSC_COUNT_LOWER_Raven_BASE_IDX 0
+
+#define mmGOLDEN_TSC_COUNT_UPPER_Raven2   0x0068
+#define mmGOLDEN_TSC_COUNT_UPPER_Raven2_BASE_IDX 0
+#define mmGOLDEN_TSC_COUNT_LOWER_Raven2   0x0069
+#define mmGOLDEN_TSC_COUNT_LOWER_Raven2_BASE_IDX 0
+
enum ta_ras_gfx_subblock {
/*CPC*/
TA_RAS_BLOCK__GFX_CPC_INDEX_START = 0,
@@ -3988,6 +3998,36 @@ static uint64_t gfx_v9_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
preempt_enable();
clock = clock_lo | (clock_hi << 32ULL);
break;
+   case IP_VERSION(9, 1, 0):
+   preempt_disable();
+   clock_hi = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Raven);
+   clock_lo = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_LOWER_Raven);
+   hi_check = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Raven);
+   /* The PWR TSC clock frequency is 100MHz, which sets 32-bit 
carry over
+* roughly every 42 seconds.
+*/
+   if (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_LOWER_Raven);
+   clock_hi = hi_check;
+   }
+   preempt_enable();
+   clock = clock_lo | (clock_hi << 32ULL);
+   break;
+   case IP_VERSION(9, 2, 2):
+   preempt_disable();
+   clock_hi = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Raven2);
+   clock_lo = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_LOWER_Raven2);
+   hi_check = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Raven2);
+   /* The PWR TSC clock frequency is 100MHz, which sets 32-bit 
carry over
+* roughly every 42 seconds.
+*/
+   if (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(PWR, 0, 
mmGOLDEN_TSC_COUNT_LOWER_Raven2);
+   clock_hi = hi_check;
+   }
+   preempt_enable();
+   clock = clock_lo | (clock_hi << 32ULL);
+   break;
default:
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(&adev->gfx.gpu_clock_mutex);

RE: drm/amdgpu/gfx9: change the reference clock for raven/raven2

[Quan, Evan]

[AMD Official Use Only - General]

Better to update the patch title with prefix as "drm/amdgpu:" instead of 
"drm/amdgpu/gfx9:".
Either way, the patch is Reviewed-by: Evan Quan 

Evan
From: Zhang, Jesse(Jie) 
Sent: Wednesday, April 12, 2023 9:25 AM
To: amd-gfx@lists.freedesktop.org; Deucher, Alexander 
; Quan, Evan ; Zhang, Yifan 

Subject: drm/amdgpu/gfx9: change the reference clock for raven/raven2


[AMD Official Use Only - General]

Due to switch to golden tsc register to get clock counter for raven/ raven2.
Chang the reference clock from 25MHZ to 100MHZ.

Signed-off-by: Jesse Zhang  jesse.zh...@amd.com<mailto:jesse.zh...@amd.com>

diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c 
b/drivers/gpu/drm/amd/amdgpu/soc15.c
index 7d04c39332ad..0367a97c606b 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -301,11 +301,10 @@ static u32 soc15_get_xclk(struct amdgpu_device *adev)
u32 reference_clock = adev->clock.spll.reference_freq;

if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(12, 0, 0) ||
-   adev->ip_versions[MP1_HWIP][0] == IP_VERSION(12, 0, 1))
-   return 1;
-   if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(10, 0, 0) ||
+   adev->ip_versions[MP1_HWIP][0] == IP_VERSION(12, 0, 1) ||
+   adev->ip_versions[MP1_HWIP][0] == IP_VERSION(10, 0, 0) ||
adev->ip_versions[MP1_HWIP][0] == IP_VERSION(10, 0, 1))
-   return reference_clock / 4;
+   return 1;

return reference_clock;
}

RE: [PATCH] drm/amd/pm: remove unused num_of_active_display variable

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: Tom Rix 
> Sent: Saturday, April 1, 2023 12:41 AM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ;
> airl...@gmail.com; dan...@ffwll.ch; nat...@kernel.org;
> ndesaulni...@google.com; Zhang, Hawking ;
> Feng, Kenneth ; Lazar, Lijo
> ; Wang, Yang(Kevin) ;
> Huang, Tim ; andrealm...@igalia.com; Liu, Kun
> ; Limonciello, Mario 
> Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org; l...@lists.linux.dev; Tom Rix 
> Subject: [PATCH] drm/amd/pm: remove unused num_of_active_display
> variable
> 
> clang with W=1 reports
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/amdgpu_smu.c:1700:6: error:
> variable
>   'num_of_active_display' set but not used [-Werror,-Wunused-but-set-
> variable]
> int num_of_active_display = 0;
> ^
> This variable is not used so remove it.
> 
> Signed-off-by: Tom Rix 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index b5d64749990e..f93f7a9ed631 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -1696,8 +1696,6 @@ static int smu_display_configuration_change(void
> *handle,
>   const struct
> amd_pp_display_configuration *display_config)  {
>   struct smu_context *smu = handle;
> - int index = 0;
> - int num_of_active_display = 0;
> 
>   if (!smu->pm_enabled || !smu->adev->pm.dpm_enabled)
>   return -EOPNOTSUPP;
> @@ -1708,11 +1706,6 @@ static int smu_display_configuration_change(void
> *handle,
>   smu_set_min_dcef_deep_sleep(smu,
>   display_config-
> >min_dcef_deep_sleep_set_clk / 100);
> 
> - for (index = 0; index < display_config-
> >num_path_including_non_display; index++) {
> - if (display_config->displays[index].controller_id != 0)
> - num_of_active_display++;
> - }
> -
>   return 0;
>  }
> 
> --
> 2.27.0

RE: [PATCH 3/3] drm/amdgpu: enable sysfs node vclk1 and dclk1 for NV3X

[Quan, Evan]

[AMD Official Use Only - General]

Please update the patch headers for the series with the prefix "drm/amd/pm" to 
align with other power changes.
With that fixed, the series is reviewed-by: Evan Quan 

Evan
> -Original Message-
> From: Tong Liu01 
> Sent: Thursday, March 30, 2023 11:15 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Chen, Horace
> ; Tuikov, Luben ;
> Koenig, Christian ; Deucher, Alexander
> ; Xiao, Jack ; Zhang,
> Hawking ; Liu, Monk ; Xu,
> Feifei ; Wang, Yang(Kevin)
> ; Liu01, Tong (Esther) 
> Subject: [PATCH 3/3] drm/amdgpu: enable sysfs node vclk1 and dclk1 for
> NV3X
> 
> Enable node pp_dpm_vclk1 and pp_dpm_dclk1 for gc11.0.2 and gc11.0.3
> 
> Signed-off-by: Tong Liu01 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index d8b9c6136fc0..e011041e3ec6 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -2125,7 +2125,9 @@ static int default_attr_update(struct
> amdgpu_device *adev, struct amdgpu_device_
>   *states = ATTR_STATE_UNSUPPORTED;
>   } else if (DEVICE_ATTR_IS(pp_dpm_vclk1)) {
>   if (!((gc_ver == IP_VERSION(10, 3, 1) ||
> -gc_ver == IP_VERSION(10, 3, 0)) && adev-
> >vcn.num_vcn_inst >= 2))
> +gc_ver == IP_VERSION(10, 3, 0) ||
> +gc_ver == IP_VERSION(11, 0, 2) ||
> +gc_ver == IP_VERSION(11, 0, 3)) && adev-
> >vcn.num_vcn_inst >= 2))
>   *states = ATTR_STATE_UNSUPPORTED;
>   } else if (DEVICE_ATTR_IS(pp_dpm_dclk)) {
>   if (!(gc_ver == IP_VERSION(10, 3, 1) || @@ -2137,7 +2139,9
> @@ static int default_attr_update(struct amdgpu_device *adev, struct
> amdgpu_device_
>   *states = ATTR_STATE_UNSUPPORTED;
>   } else if (DEVICE_ATTR_IS(pp_dpm_dclk1)) {
>   if (!((gc_ver == IP_VERSION(10, 3, 1) ||
> -gc_ver == IP_VERSION(10, 3, 0)) && adev-
> >vcn.num_vcn_inst >= 2))
> +gc_ver == IP_VERSION(10, 3, 0) ||
> +gc_ver == IP_VERSION(11, 0, 2) ||
> +gc_ver == IP_VERSION(11, 0, 3)) && adev-
> >vcn.num_vcn_inst >= 2))
>   *states = ATTR_STATE_UNSUPPORTED;
>   } else if (DEVICE_ATTR_IS(pp_power_profile_mode)) {
>   if (amdgpu_dpm_get_power_profile_mode(adev, NULL) ==
> -EOPNOTSUPP)
> --
> 2.34.1

RE: [PATCH 1/3] drm/amdgpu: add sysfs node vclk1 and dclk1

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Tong Liu01 
> Sent: Wednesday, March 29, 2023 6:51 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Chen, Horace
> ; Tuikov, Luben ;
> Koenig, Christian ; Deucher, Alexander
> ; Xiao, Jack ; Zhang,
> Hawking ; Liu, Monk ; Xu,
> Feifei ; Wang, Yang(Kevin)
> ; Liu01, Tong (Esther) 
> Subject: [PATCH 1/3] drm/amdgpu: add sysfs node vclk1 and dclk1
> 
> User can check pp_dpm_vclk1 and pp_dpm_dclk1 for DPM frequency of
> vcn and dcn
> 
> Signed-off-by: Tong Liu01 
> ---
>  .../gpu/drm/amd/include/kgd_pp_interface.h|  2 ++
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 32
> +++
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |  8 +
>  3 files changed, 42 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> index 86b6b0c9fb02..9f542f6e19ed 100644
> --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> @@ -104,7 +104,9 @@ enum pp_clock_type {
>   PP_FCLK,
>   PP_DCEFCLK,
>   PP_VCLK,
> + PP_VCLK1,
>   PP_DCLK,
> + PP_DCLK1,
>   OD_SCLK,
>   OD_MCLK,
>   OD_VDDC_CURVE,
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index d75a67cfe523..9991447b5f14 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -1180,6 +1180,21 @@ static ssize_t amdgpu_set_pp_dpm_vclk(struct
> device *dev,
>   return amdgpu_set_pp_dpm_clock(dev, PP_VCLK, buf, count);
>  }
> 
> +static ssize_t amdgpu_get_pp_dpm_vclk1(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return amdgpu_get_pp_dpm_clock(dev, PP_VCLK1, buf);
> +}
> +
> +static ssize_t amdgpu_set_pp_dpm_vclk1(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + return amdgpu_set_pp_dpm_clock(dev, PP_VCLK1, buf, count);
> +}
> +
>  static ssize_t amdgpu_get_pp_dpm_dclk(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
> @@ -1195,6 +1210,21 @@ static ssize_t amdgpu_set_pp_dpm_dclk(struct
> device *dev,
>   return amdgpu_set_pp_dpm_clock(dev, PP_DCLK, buf, count);
>  }
> 
> +static ssize_t amdgpu_get_pp_dpm_dclk1(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return amdgpu_get_pp_dpm_clock(dev, PP_DCLK, buf);
"PP_DCLK" here should be "PP_DCLK1" I believe. Might a copy-and-paste error?
> +}
> +
> +static ssize_t amdgpu_set_pp_dpm_dclk1(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + return amdgpu_set_pp_dpm_clock(dev, PP_DCLK, buf, count);
Same here.

Evan
> +}
> +
>  static ssize_t amdgpu_get_pp_dpm_dcefclk(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
> @@ -2002,7 +2032,9 @@ static struct amdgpu_device_attr
> amdgpu_device_attrs[] = {
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_fclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_vclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> + AMDGPU_DEVICE_ATTR_RW(pp_dpm_vclk1,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_dclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> + AMDGPU_DEVICE_ATTR_RW(pp_dpm_dclk1,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_dcefclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_pcie,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_sclk_od,
>   ATTR_FLAG_BASIC),
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index 94fe8593444a..056ac2b512eb 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -2022,8 +2022,12 @@ static int smu_force_ppclk_levels(void *handle,
>   clk_type = SMU_DCEFCLK; break;
>   case PP_VCLK:
>   clk_type = SMU_VCLK; break;
> + case PP_VCLK1:
> + clk_type = SMU_VCLK1; break;
>   case PP_DCLK:
>   clk_type = SMU_DCLK; break;
> + case PP_DCLK1:
> + clk_type = SMU_DCLK1; break;
>   case OD_SCLK:
>

RE: [PATCH] drm/amdgpu: enable sysfs node pp_dpm_vclk1 for some asics

[Quan, Evan]

[AMD Official Use Only - General]

IIRC, the VCLK1 always have the same frequency as VCLK0 with our current 
implementation.
So, is it necessary to provide another sysfs node for checking vclk1 frequency?

BR
Evan
> -Original Message-
> From: Tong Liu01 
> Sent: Tuesday, March 28, 2023 7:42 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Chen, Horace
> ; Tuikov, Luben ;
> Koenig, Christian ; Deucher, Alexander
> ; Xiao, Jack ; Zhang,
> Hawking ; Liu, Monk ; Xu,
> Feifei ; Wang, Yang(Kevin)
> ; Liu01, Tong (Esther) 
> Subject: [PATCH] drm/amdgpu: enable sysfs node pp_dpm_vclk1 for some
> asics
> 
> Add sysfs node pp_dpm_vclk1 for gc11.0.3
> 
> Signed-off-by: Tong Liu01 
> ---
>  .../gpu/drm/amd/include/kgd_pp_interface.h|  1 +
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 22
> +++
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c |  4 
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> index 86b6b0c9fb02..fe75497eeeab 100644
> --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> @@ -104,6 +104,7 @@ enum pp_clock_type {
>   PP_FCLK,
>   PP_DCEFCLK,
>   PP_VCLK,
> + PP_VCLK1,
>   PP_DCLK,
>   OD_SCLK,
>   OD_MCLK,
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index d75a67cfe523..1da6e9469450 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -1180,6 +1180,21 @@ static ssize_t amdgpu_set_pp_dpm_vclk(struct
> device *dev,
>   return amdgpu_set_pp_dpm_clock(dev, PP_VCLK, buf, count);
>  }
> 
> +static ssize_t amdgpu_get_pp_dpm_vclk1(struct device *dev,
> + struct device_attribute *attr,
> + char *buf)
> +{
> + return amdgpu_get_pp_dpm_clock(dev, PP_VCLK1, buf);
> +}
> +
> +static ssize_t amdgpu_set_pp_dpm_vclk1(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t count)
> +{
> + return amdgpu_set_pp_dpm_clock(dev, PP_VCLK1, buf, count);
> +}
> +
>  static ssize_t amdgpu_get_pp_dpm_dclk(struct device *dev,
>   struct device_attribute *attr,
>   char *buf)
> @@ -2002,6 +2017,7 @@ static struct amdgpu_device_attr
> amdgpu_device_attrs[] = {
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_socclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_fclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_vclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> + AMDGPU_DEVICE_ATTR_RW(pp_dpm_vclk1,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_dclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_dcefclk,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
>   AMDGPU_DEVICE_ATTR_RW(pp_dpm_pcie,
>   ATTR_FLAG_BASIC|ATTR_FLAG_ONEVF),
> @@ -2091,6 +2107,12 @@ static int default_attr_update(struct
> amdgpu_device *adev, struct amdgpu_device_
> gc_ver == IP_VERSION(11, 0, 2) ||
> gc_ver == IP_VERSION(11, 0, 3)))
>   *states = ATTR_STATE_UNSUPPORTED;
> + } else if (DEVICE_ATTR_IS(pp_dpm_vclk1)) {
> + if (!((gc_ver == IP_VERSION(10, 3, 1) ||
> +gc_ver == IP_VERSION(10, 3, 0) ||
> +gc_ver == IP_VERSION(11, 0, 2) ||
> +gc_ver == IP_VERSION(11, 0, 3)) && adev-
> >vcn.num_vcn_inst >= 2))
> + *states = ATTR_STATE_UNSUPPORTED;
>   } else if (DEVICE_ATTR_IS(pp_dpm_dclk)) {
>   if (!(gc_ver == IP_VERSION(10, 3, 1) ||
> gc_ver == IP_VERSION(10, 3, 0) ||
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index b5d64749990e..bffbef3f666d 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -2006,6 +2006,8 @@ static int smu_force_ppclk_levels(void *handle,
>   clk_type = SMU_DCEFCLK; break;
>   case PP_VCLK:
>   clk_type = SMU_VCLK; break;
> + case PP_VCLK1:
> + clk_type = SMU_VCLK1; break;
>   case PP_DCLK:
>   clk_type = SMU_DCLK; break;
>   case OD_SCLK:
> @@ -2393,6 +2395,8 @@ static enum smu_clk_type
> smu_convert_to_smuclk(enum pp_clock_type type)
>   clk_type = SMU_DCEFCLK; break;
>   case PP_VCLK:
>   clk_type = SMU_VCLK; break;
> + case PP_VCLK1:
> + clk_type = SMU_VCLK1; break;
>   case PP_DCLK:
>   clk_type = SMU_DCLK; break;
>   case OD_SCLK:
> --
> 2.34.1

RE: [PATCH] drm/amd/pm: re-enable the gfx imu when smu resume

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of Tim
> Huang
> Sent: Friday, March 24, 2023 3:08 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Zhang, Yifan
> ; Ma, Li ; Du, Xiaojian
> ; Huang, Tim 
> Subject: [PATCH] drm/amd/pm: re-enable the gfx imu when smu resume
> 
> If the gfx imu is poweroff when suspend, then
> it need to be re-enabled when resume.
> 
> Signed-off-by: Tim Huang 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 40
> ---
>  1 file changed, 28 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index b5d64749990e..94fe8593444a 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -162,10 +162,15 @@ int smu_get_dpm_freq_range(struct smu_context
> *smu,
> 
>  int smu_set_gfx_power_up_by_imu(struct smu_context *smu)
>  {
> - if (!smu->ppt_funcs || !smu->ppt_funcs-
> >set_gfx_power_up_by_imu)
> - return -EOPNOTSUPP;
This assumes that all APUs need to support the ->set_gfx_power_up_by_imu int 
interface.
Otherwise, the driver loading will fail?
Is that expected?

Evan
> + int ret = 0;
> + struct amdgpu_device *adev = smu->adev;
> 
> - return smu->ppt_funcs->set_gfx_power_up_by_imu(smu);
> + if (smu->ppt_funcs->set_gfx_power_up_by_imu) {
> + ret = smu->ppt_funcs->set_gfx_power_up_by_imu(smu);
> + if (ret)
> + dev_err(adev->dev, "Failed to enable gfx imu!\n");
> + }
> + return ret;
>  }
> 
>  static u32 smu_get_mclk(void *handle, bool low)
> @@ -196,6 +201,19 @@ static u32 smu_get_sclk(void *handle, bool low)
>   return clk_freq * 100;
>  }
> 
> +static int smu_set_gfx_imu_enable(struct smu_context *smu)
> +{
> + struct amdgpu_device *adev = smu->adev;
> +
> + if (adev->firmware.load_type != AMDGPU_FW_LOAD_PSP)
> + return 0;
> +
> + if (amdgpu_in_reset(smu->adev) || adev->in_s0ix)
> + return 0;
> +
> + return smu_set_gfx_power_up_by_imu(smu);
> +}
> +
>  static int smu_dpm_set_vcn_enable(struct smu_context *smu,
> bool enable)
>  {
> @@ -1396,15 +1414,9 @@ static int smu_hw_init(void *handle)
>   }
> 
>   if (smu->is_apu) {
> - if ((smu->ppt_funcs->set_gfx_power_up_by_imu) &&
> - likely(adev->firmware.load_type ==
> AMDGPU_FW_LOAD_PSP)) {
> - ret = smu->ppt_funcs-
> >set_gfx_power_up_by_imu(smu);
> - if (ret) {
> - dev_err(adev->dev, "Failed to Enable gfx
> imu!\n");
> - return ret;
> - }
> - }
> -
> + ret = smu_set_gfx_imu_enable(smu);
> + if (ret)
> + return ret;
>   smu_dpm_set_vcn_enable(smu, true);
>   smu_dpm_set_jpeg_enable(smu, true);
>   smu_set_gfx_cgpg(smu, true);
> @@ -1681,6 +1693,10 @@ static int smu_resume(void *handle)
>   return ret;
>   }
> 
> + ret = smu_set_gfx_imu_enable(smu);
> + if (ret)
> + return ret;
> +
>   smu_set_gfx_cgpg(smu, true);
> 
>   smu->disable_uclk_switch = 0;
> --
> 2.25.1

RE: [Resend PATCH v1 3/3] drm/amd/pm: vangogh: support to send SMT enable message

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Wenyou Yang
> Sent: Wednesday, March 22, 2023 5:16 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui 
> Cc: Yuan, Perry ; Li, Ying ; amd-
> g...@lists.freedesktop.org; Yang, WenYou ; Liu,
> Kun ; Liang, Richard qi 
> Subject: [Resend PATCH v1 3/3] drm/amd/pm: vangogh: support to send
> SMT enable message
> 
> Add the support to PPSMC_MSG_SetCClkSMTEnable(0x58) message to
> pmfw
> for vangogh.
> 
> Signed-off-by: Wenyou Yang 
> ---
>  .../pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h|  3 ++-
>  drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h  |  3 ++-
>  .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c  | 19
> +++
>  3 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git
> a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> index 7471e2df2828..2b182dbc6f9c 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v11_5_ppsmc.h
> @@ -111,7 +111,8 @@
>  #define PPSMC_MSG_GetGfxOffStatus   0x50
>  #define PPSMC_MSG_GetGfxOffEntryCount   0x51
>  #define PPSMC_MSG_LogGfxOffResidency0x52
> -#define PPSMC_Message_Count0x53
> +#define PPSMC_MSG_SetCClkSMTEnable  0x58
> +#define PPSMC_Message_Count0x54
This seems not right. The message count should be bigger than the index of any 
other message.
That is PPSMC_Message_Count should be 0x59 or bigger.
> 
>  //Argument for PPSMC_MSG_GfxDeviceDriverReset
>  enum {
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> index 297b70b9388f..820812d910bf 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> @@ -245,7 +245,8 @@
>   __SMU_DUMMY_MAP(AllowGpo),  \
>   __SMU_DUMMY_MAP(Mode2Reset),\
>   __SMU_DUMMY_MAP(RequestI2cTransaction), \
> - __SMU_DUMMY_MAP(GetMetricsTable),
> + __SMU_DUMMY_MAP(GetMetricsTable), \
> + __SMU_DUMMY_MAP(SetCClkSMTEnable),
> 
>  #undef __SMU_DUMMY_MAP
>  #define __SMU_DUMMY_MAP(type)SMU_MSG_##type
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 7433dcaa16e0..f0eeb42df96b 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -141,6 +141,7 @@ static struct cmn2asic_msg_mapping
> vangogh_message_map[SMU_MSG_MAX_COUNT] = {
>   MSG_MAP(GetGfxOffStatus,
> PPSMC_MSG_GetGfxOffStatus,
>   0),
>   MSG_MAP(GetGfxOffEntryCount,
> PPSMC_MSG_GetGfxOffEntryCount,0),
>   MSG_MAP(LogGfxOffResidency,
> PPSMC_MSG_LogGfxOffResidency, 0),
> + MSG_MAP(SetCClkSMTEnable,
> PPSMC_MSG_SetCClkSMTEnable,
>   0),
>  };
> 
>  static struct cmn2asic_mapping
> vangogh_feature_mask_map[SMU_FEATURE_COUNT] = {
> @@ -2428,6 +2429,23 @@ static u32 vangogh_get_gfxoff_entrycount(struct
> smu_context *smu, uint64_t *entr
>   return ret;
>  }
> 
> +static int vangogh_set_cpu_smt_enable(struct smu_context *smu, bool
> enable)
> +{
> + int ret = 0;
> +
> + if (enable) {
> + ret = smu_cmn_send_smc_msg_with_param(smu,
> +
> SMU_MSG_SetCClkSMTEnable,
> +   1, NULL);
> + } else {
> + ret = smu_cmn_send_smc_msg_with_param(smu,
> +
> SMU_MSG_SetCClkSMTEnable,
> +   0, NULL);
> + }
> +
> + return ret;
It seems the whole bunch of chunks can be simplified as 
"return smu_cmn_send_smc_msg_with_param(smu, SMU_MSG_SetCClkSMTEnable, enable ? 
1 : 0, NULL);"

BR
Evan
> +}
> +
>  static const struct pptable_funcs vangogh_ppt_funcs = {
> 
>   .check_fw_status = smu_v11_0_check_fw_status,
> @@ -2474,6 +2492,7 @@ static const struct pptable_funcs
> vangogh_ppt_funcs = {
>   .get_power_limit = vangogh_get_power_limit,
>   .set_power_limit = vangogh_set_power_limit,
>   .get_vbios_bootup_values = smu_v11_0_get_vbios_bootup_values,
> + .set_cpu_smt_enable = vangogh_set_cpu_smt_enable,
>  };
> 
>  void vangogh_set_ppt_funcs(struct smu_context *smu)
> --
> 2.39.2

RE: [Resend PATCH v1 2/3] drm/amd/pm: send the SMT-enable message to pmfw

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Wenyou Yang
> Sent: Wednesday, March 22, 2023 5:16 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Pan, Xinhui 
> Cc: Yuan, Perry ; Li, Ying ; amd-
> g...@lists.freedesktop.org; Yang, WenYou ; Liu,
> Kun ; Liang, Richard qi 
> Subject: [Resend PATCH v1 2/3] drm/amd/pm: send the SMT-enable
> message to pmfw
> 
> When the CPU SMT status change in the fly, sent the SMT-enable
> message to pmfw to notify it that the SMT status changed.
> 
> Signed-off-by: Wenyou Yang 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 41
> +++
>  drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h |  5 +++
>  2 files changed, 46 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index b5d64749990e..5cd85a9d149d 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -22,6 +22,7 @@
> 
>  #define SWSMU_CODE_LAYER_L1
> 
> +#include 
>  #include 
>  #include 
> 
> @@ -69,6 +70,14 @@ static int smu_set_fan_speed_rpm(void *handle,
> uint32_t speed);
>  static int smu_set_gfx_cgpg(struct smu_context *smu, bool enabled);
>  static int smu_set_mp1_state(void *handle, enum pp_mp1_state
> mp1_state);
> 
> +static int smt_notifier_callback(struct notifier_block *nb, unsigned long
> action, void *data);
> +
> +extern struct raw_notifier_head smt_notifier_head;
> +
> +static struct notifier_block smt_notifier = {
> + .notifier_call = smt_notifier_callback,
> +};
By embedding smt_notifier into "struct smu_context" structure, you do not need 
this smt_notifer and current_smu below.
You can refer to omap_dma_busy_notifier().

BR
Evan
> +
>  static int smu_sys_get_pp_feature_mask(void *handle,
>  char *buf)
>  {
> @@ -625,6 +634,8 @@ static int smu_set_funcs(struct amdgpu_device
> *adev)
>   return 0;
>  }
> 
> +static struct smu_context *current_smu;
> +
>  static int smu_early_init(void *handle)
>  {
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> @@ -645,6 +656,7 @@ static int smu_early_init(void *handle)
>   mutex_init(&smu->message_lock);
> 
>   adev->powerplay.pp_handle = smu;
> + current_smu = smu;
>   adev->powerplay.pp_funcs = &swsmu_pm_funcs;
> 
>   r = smu_set_funcs(adev);
> @@ -1105,6 +1117,8 @@ static int smu_sw_init(void *handle)
>   if (!smu->ppt_funcs->get_fan_control_mode)
>   smu->adev->pm.no_fan = true;
> 
> + raw_notifier_chain_register(&smt_notifier_head, &smt_notifier);
> +
>   return 0;
>  }
> 
> @@ -1122,6 +1136,8 @@ static int smu_sw_fini(void *handle)
> 
>   smu_fini_microcode(smu);
> 
> + raw_notifier_chain_unregister(&smt_notifier_head, &smt_notifier);
> +
>   return 0;
>  }
> 
> @@ -3241,3 +3257,28 @@ int smu_send_hbm_bad_channel_flag(struct
> smu_context *smu, uint32_t size)
> 
>   return ret;
>  }
> +
> +static int smu_set_cpu_smt_enable(struct smu_context *smu, bool enable)
> +{
> + int ret = -EINVAL;
> +
> + if (smu->ppt_funcs && smu->ppt_funcs->set_cpu_smt_enable)
> + ret = smu->ppt_funcs->set_cpu_smt_enable(smu, enable);
> +
> + return ret;
> +}
> +
> +static int smt_notifier_callback(struct notifier_block *nb,
> +  unsigned long action, void *data)
> +{
> + struct smu_context *smu = current_smu;
> + int ret = NOTIFY_OK;
> +
> + ret = (action == SMT_ENABLED) ?
> + smu_set_cpu_smt_enable(smu, true) :
> + smu_set_cpu_smt_enable(smu, false);
> + if (ret)
> + ret = NOTIFY_BAD;
> +
> + return ret;
> +}
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> index 09469c750a96..7c6594bba796 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> @@ -1354,6 +1354,11 @@ struct pptable_funcs {
>* @init_pptable_microcode: Prepare the pptable microcode to
> upload via PSP
>*/
>   int (*init_pptable_microcode)(struct smu_context *smu);
> +
> + /**
> +  * @set_cpu_smt_enable: Set the CPU SMT status
> +  */
> + int (*set_cpu_smt_enable)(struct smu_context *smu, bool enable);
>  };
> 
>  typedef enum {
> --
> 2.39.2

RE: [PATCH] drm/amdgpu: improve debug VRAM access performance using sdma

[Quan, Evan]

[AMD Official Use Only - General]

OK, I see. Thanks for the explanations.

BR
Evan
> -Original Message-
> From: Koenig, Christian 
> Sent: Tuesday, March 21, 2023 1:32 AM
> To: Kim, Jonathan ; Christian König
> ; Quan, Evan ;
> amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix 
> Subject: Re: [PATCH] drm/amdgpu: improve debug VRAM access
> performance using sdma
> 
> Ah, yes! GART doesn't need to be read to make a GTT allocation.
> 
> When GART becomes ready it will be filled with all the buffers which were
> allocated before it was ready.
> 
> So this is perfectly fine.
> 
> Thanks,
> Christian.
> 
> Am 20.03.23 um 18:24 schrieb Kim, Jonathan:
> > [Public]
> >
> > This was a long time ago but I think we agreed allocation was ok before
> GART was ready.
> > IIRC, there was also some mentioned related scenario where APUs needed
> to work without VRAM but allocations were required (but I don't know the
> details regarding that).
> > I vaguely remember the requirement for GART readiness for the bounce
> buffer allocation caused some problems elsewhere.
> > Are there problems observed with the bounce buffer being allocated
> without GART readiness?
> >
> > Thanks,
> >
> > Jon
> >> -Original Message-
> >> From: Christian König 
> >> Sent: Monday, March 20, 2023 1:02 PM
> >> To: Quan, Evan ; Kim, Jonathan
> >> ; amd-gfx@lists.freedesktop.org
> >> Cc: Kuehling, Felix ; Koenig, Christian
> >> 
> >> Subject: Re: [PATCH] drm/amdgpu: improve debug VRAM access
> >> performance using sdma
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> I don't think so. Have we recently re-ordered something here?
> >>
> >> Christian.
> >>
> >> Am 20.03.23 um 08:05 schrieb Quan, Evan:
> >>> [AMD Official Use Only - General]
> >>>
> >>> I happened to find the sdma_access_bo allocation from GTT seems
> >> performing before gart is ready.
> >>> That makes the "amdgpu_gart_map" is skipped since adev->gart.ptr is
> >>> still
> >> NULL.
> >>> Is that done intentionally ?
> >>>
> >>> Evan
> >>>> -Original Message-
> >>>> From: amd-gfx  On Behalf
> Of
> >>>> Jonathan Kim
> >>>> Sent: Wednesday, January 5, 2022 3:12 AM
> >>>> To: amd-gfx@lists.freedesktop.org
> >>>> Cc: Kuehling, Felix ; Kim, Jonathan
> >>>> ; Koenig, Christian
> >> 
> >>>> Subject: [PATCH] drm/amdgpu: improve debug VRAM access
> performance
> >>>> using sdma
> >>>>
> >>>> For better performance during VRAM access for debugged processes,
> >>>> do read/write copies over SDMA.
> >>>>
> >>>> In order to fulfill post mortem debugging on a broken device,
> >>>> fallback to stable MMIO access when gpu recovery is disabled or
> >>>> when job
> >> submission
> >>>> time outs are set to max.  Failed SDMA access should automatically
> >>>> fall back to MMIO access.
> >>>>
> >>>> Use a pre-allocated GTT bounce buffer pre-mapped into GART to avoid
> >>>> page-table updates and TLB flushes on access.
> >>>>
> >>>> Signed-off-by: Jonathan Kim 
> >>>> ---
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 78
> >>>> +
> >>>>drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  5 +-
> >>>>2 files changed, 82 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>>> index 367abed1d6e6..512df4c09772 100644
> >>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> >>>> @@ -48,6 +48,7 @@
> >>>>#include 
> >>>>
> >>>>#include 
> >>>> +#include 
> >>>>
> >>>>#include "amdgpu.h"
> >>>>#include "amdgpu_object.h"
> >>>> @@ -1429,6 +1430,70 @@ static void
> >> amdgpu_ttm_vram_mm_access(struct
> >>>> amdgpu_device *adev

RE: [PATCH 19/19] drm/amdgpu/smu11: enable TEMP_DEPENDENT_VMIN for navi1x

[Quan, Evan]

[AMD Official Use Only - General]

Better to update the subject with prefix as "drm/amd/pm" to align with other 
power changes.
Either way the patch is
Reviewed-by: Evan Quan 

BR
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> Qingqing Zhuo
> Sent: Saturday, March 18, 2023 3:56 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Wang, Chao-kai (Stylon) ; Li, Sun peng (Leo)
> ; Wentland, Harry ;
> Zhuo, Qingqing (Lillian) ; Siqueira, Rodrigo
> ; Li, Roman ; Chiu,
> Solomon ; Pillai, Aurabindo
> ; Lin, Wayne ; Deucher,
> Alexander ; Lakha, Bhawanpreet
> ; Gutierrez, Agustin
> ; Kotarac, Pavle 
> Subject: [PATCH 19/19] drm/amdgpu/smu11: enable
> TEMP_DEPENDENT_VMIN for navi1x
> 
> From: Alex Deucher 
> 
> May help stability with some navi1x boards.
> 
> Hopefully this helps with stability with multiple monitors and would allow us
> to re-enable MPC_SPLIT_DYNAMIC in the DC code for better power savings.
> 
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2196
> 
> Reviewed-by: Rodrigo Siqueira 
> Acked-by: Qingqing Zhuo 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> index 95da6dd1cc65..c4000518dc56 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> @@ -304,7 +304,8 @@ navi10_get_allowed_feature_mask(struct
> smu_context *smu,
>   | FEATURE_MASK(FEATURE_GFX_SS_BIT)
>   | FEATURE_MASK(FEATURE_APCC_DFLL_BIT)
>   | FEATURE_MASK(FEATURE_FW_CTF_BIT)
> - |
> FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT);
> + |
> FEATURE_MASK(FEATURE_OUT_OF_BAND_MONITOR_BIT)
> + |
> FEATURE_MASK(FEATURE_TEMP_DEPENDENT_VMIN_BIT);
> 
>   if (adev->pm.pp_feature & PP_SCLK_DPM_MASK)
>   *(uint64_t *)feature_mask |=
> FEATURE_MASK(FEATURE_DPM_GFXCLK_BIT);
> --
> 2.34.1

RE: [PATCH] drm/amdgpu: improve debug VRAM access performance using sdma

[Quan, Evan]

[AMD Official Use Only - General]

I happened to find the sdma_access_bo allocation from GTT seems performing 
before gart is ready.
That makes the "amdgpu_gart_map" is skipped since adev->gart.ptr is still NULL.
Is that done intentionally ?

Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> Jonathan Kim
> Sent: Wednesday, January 5, 2022 3:12 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Kuehling, Felix ; Kim, Jonathan
> ; Koenig, Christian 
> Subject: [PATCH] drm/amdgpu: improve debug VRAM access performance
> using sdma
> 
> For better performance during VRAM access for debugged processes, do
> read/write copies over SDMA.
> 
> In order to fulfill post mortem debugging on a broken device, fallback to
> stable MMIO access when gpu recovery is disabled or when job submission
> time outs are set to max.  Failed SDMA access should automatically fall
> back to MMIO access.
> 
> Use a pre-allocated GTT bounce buffer pre-mapped into GART to avoid
> page-table updates and TLB flushes on access.
> 
> Signed-off-by: Jonathan Kim 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 78
> +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h |  5 +-
>  2 files changed, 82 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 367abed1d6e6..512df4c09772 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -48,6 +48,7 @@
>  #include 
> 
>  #include 
> +#include 
> 
>  #include "amdgpu.h"
>  #include "amdgpu_object.h"
> @@ -1429,6 +1430,70 @@ static void amdgpu_ttm_vram_mm_access(struct
> amdgpu_device *adev, loff_t pos,
>   }
>  }
> 
> +static int amdgpu_ttm_access_memory_sdma(struct ttm_buffer_object
> *bo,
> + unsigned long offset, void *buf, int
> len, int write)
> +{
> + struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
> + struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
> + struct amdgpu_job *job;
> + struct dma_fence *fence;
> + uint64_t src_addr, dst_addr;
> + unsigned int num_dw;
> + int r, idx;
> +
> + if (len != PAGE_SIZE)
> + return -EINVAL;
> +
> + if (!adev->mman.sdma_access_ptr)
> + return -EACCES;
> +
> + r = drm_dev_enter(adev_to_drm(adev), &idx);
> + if (r)
> + return r;
> +
> + if (write)
> + memcpy(adev->mman.sdma_access_ptr, buf, len);
> +
> + num_dw = ALIGN(adev->mman.buffer_funcs->copy_num_dw, 8);
> + r = amdgpu_job_alloc_with_ib(adev, num_dw * 4,
> AMDGPU_IB_POOL_DELAYED, &job);
> + if (r)
> + goto out;
> +
> + src_addr = write ? amdgpu_bo_gpu_offset(adev-
> >mman.sdma_access_bo) :
> + amdgpu_bo_gpu_offset(abo);
> + dst_addr = write ? amdgpu_bo_gpu_offset(abo) :
> + amdgpu_bo_gpu_offset(adev-
> >mman.sdma_access_bo);
> + amdgpu_emit_copy_buffer(adev, &job->ibs[0], src_addr, dst_addr,
> PAGE_SIZE, false);
> +
> + amdgpu_ring_pad_ib(adev->mman.buffer_funcs_ring, &job->ibs[0]);
> + WARN_ON(job->ibs[0].length_dw > num_dw);
> +
> + r = amdgpu_job_submit(job, &adev->mman.entity,
> AMDGPU_FENCE_OWNER_UNDEFINED, &fence);
> + if (r) {
> + amdgpu_job_free(job);
> + goto out;
> + }
> +
> + if (!dma_fence_wait_timeout(fence, false, adev->sdma_timeout))
> + r = -ETIMEDOUT;
> + dma_fence_put(fence);
> +
> + if (!(r || write))
> + memcpy(buf, adev->mman.sdma_access_ptr, len);
> +out:
> + drm_dev_exit(idx);
> + return r;
> +}
> +
> +static inline bool amdgpu_ttm_allow_post_mortem_debug(struct
> amdgpu_device *adev)
> +{
> + return amdgpu_gpu_recovery == 0 ||
> + adev->gfx_timeout == MAX_SCHEDULE_TIMEOUT ||
> + adev->compute_timeout == MAX_SCHEDULE_TIMEOUT ||
> + adev->sdma_timeout == MAX_SCHEDULE_TIMEOUT ||
> + adev->video_timeout == MAX_SCHEDULE_TIMEOUT;
> +}
> +
>  /**
>   * amdgpu_ttm_access_memory - Read or Write memory that backs a
> buffer object.
>   *
> @@ -1453,6 +1518,10 @@ static int amdgpu_ttm_access_memory(struct
> ttm_buffer_object *bo,
>   if (bo->resource->mem_type != TTM_PL_VRAM)
>   return -EIO;
> 
> + if (!amdgpu_ttm_allow_post_mortem_debug(adev) &&
> + !amdgpu_ttm_access_memory_sdma(bo, offset, buf,
> len, write))
> + return len;
> +
>   amdgpu_res_first(bo->resource, offset, len, &cursor);
>   while (cursor.remaining) {
>   size_t count, size = cursor.size;
> @@ -1793,6 +1862,12 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
>   return r;
>   }
> 
> + if (amdgpu_bo_create_kernel(adev, PAGE_SIZE, PAGE_SIZE,
> + AMDGPU_GEM_DOMAIN_GTT,
> + &adev->mman.sdma_access_bo, NULL,
> + adev->mman.sdma_acces

RE: [PATCH v2] drm/amdgpu: resove reboot exception for si oland

[Quan, Evan]

[AMD Official Use Only - General]

I'm OK with the drop of si_set_temperature_range() in late_init.
Meanwhile, it's still not clear to me how this could lead reboot exception.
Can you dig this a little bit further?
For example, can you check whether the 
operation(si_thermal_start_thermal_controller()) actually already failed in 
hw_init(si_dpm_enable more specifically)?

@@ -6918,7 +6918,11 @@ static int si_dpm_enable(struct amdgpu_device *adev)
si_start_dpm(adev);

si_enable_auto_throttle_source(adev, SI_DPM_AUTO_THROTTLE_SRC_THERMAL, 
true);
-   si_thermal_start_thermal_controller(adev);
+   ret = si_thermal_start_thermal_controller(adev);
+   if (ret) {
+   DRM_ERROR("si_thermal_start_thermal_controller failed\n");
+   return ret;
+   }

ni_update_current_ps(adev, boot_ps);

BR
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> Zhenneng Li
> Sent: Monday, March 13, 2023 10:57 AM
> To: Chen, Guchun 
> Cc: David Airlie ; Pan, Xinhui ;
> Zhenneng Li ; amd-gfx@lists.freedesktop.org;
> Daniel Vetter ; Deucher, Alexander
> ; Koenig, Christian
> 
> Subject: [PATCH v2] drm/amdgpu: resove reboot exception for si oland
> 
> During reboot test on arm64 platform, it may failure
> on boot.
> 
> The error message are as follows:
> [6.996395][ 7] [  T295] [drm:amdgpu_device_ip_late_init [amdgpu]]
> *ERROR*
>   late_init of IP block  failed -22
> [7.006919][ 7] [  T295] amdgpu :04:00.0: amdgpu_device_ip_late_init
> failed
> [7.014224][ 7] [  T295] amdgpu :04:00.0: Fatal error during GPU init
> ---
>  drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 12 
>  1 file changed, 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> index d6d9e3b1b2c0..ca9bce895dbe 100644
> --- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c
> @@ -7626,18 +7626,6 @@ static int si_dpm_process_interrupt(struct
> amdgpu_device *adev,
> 
>  static int si_dpm_late_init(void *handle)
>  {
> - int ret;
> - struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> -
> - if (!adev->pm.dpm_enabled)
> - return 0;
> -
> - ret = si_set_temperature_range(adev);
> - if (ret)
> - return ret;
> -#if 0 //TODO ?
> - si_dpm_powergate_uvd(adev, true);
> -#endif
>   return 0;
>  }
> 
> --
> 2.25.1

RE: [PATCH v3 2/2] drm/probe_helper: warning on poll_enabled for issue catching

[Quan, Evan]

[AMD Official Use Only - General]

Series is acked-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of
> Guchun Chen
> Sent: Friday, March 10, 2023 9:02 AM
> To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> Deucher, Alexander ; Zhang, Hawking
> ; dmitry.barysh...@linaro.org;
> spassw...@web.de; m...@fireburn.co.uk
> Cc: Chen, Guchun 
> Subject: [PATCH v3 2/2] drm/probe_helper: warning on poll_enabled for
> issue catching
> 
> In order to catch issues in other drivers to ensure proper call sequence of
> polling function.
> 
> v2: drop Fixes tag in commit message
> 
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2411
> Reported-by: Bert Karwatzki 
> Suggested-by: Dmitry Baryshkov 
> Signed-off-by: Guchun Chen 
> ---
>  drivers/gpu/drm/drm_probe_helper.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 8127be134c39..85e0e80d4a52 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -852,6 +852,8 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
>   */
>  void drm_kms_helper_poll_disable(struct drm_device *dev)  {
> + WARN_ON(!dev->mode_config.poll_enabled);
> +
>   if (dev->mode_config.poll_running)
>   drm_kms_helper_disable_hpd(dev);
> 
> --
> 2.25.1

RE: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after resume

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Deucher, Alexander 
> Sent: Wednesday, March 8, 2023 11:20 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Błażej Szczygieł
> ; Quan, Evan 
> Subject: [PATCH 2/2] drm/amd/pm: Fix navi10 incorrect OD volage after
> resume
> 
> Always setup overdrive tables after resume. Preserve only some
> user-defined settings in user_overdrive_table if they're set.
> 
> Copy restored user_overdrive_table into od_table to get correct
> values.
> 
> On cold boot, BTC was triggered and GfxVfCurve was calibrated. We
> got VfCurve settings (a). On resuming back, BTC will be triggered
> again and GfxVfCurve will be recalibrated. VfCurve settings (b)
> got may be different from those of cold boot.  So if we reuse
> those VfCurve settings (a) got on cold boot on suspend, we can
> run into discrepencies.
> 
> Based on the sienna cichlid patch from Błażej Szczygieł
> 
> 
> Cc: Błażej Szczygieł 
> Cc: Evan Quan 
> Signed-off-by: Alex Deucher 
> ---
>  .../gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c   | 47
> +++
>  1 file changed, 37 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> index 95da6dd1cc65..68201d8e1c72 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/navi10_ppt.c
> @@ -2510,16 +2510,9 @@ static int navi10_set_default_od_settings(struct
> smu_context *smu)
>   (OverDriveTable_t *)smu->smu_table.boot_overdrive_table;
>   OverDriveTable_t *user_od_table =
>   (OverDriveTable_t *)smu->smu_table.user_overdrive_table;
> + OverDriveTable_t user_od_table_bak;
>   int ret = 0;
> 
> - /*
> -  * For S3/S4/Runpm resume, no need to setup those overdrive
> tables again as
> -  *   - either they already have the default OD settings got during cold
> bootup
> -  *   - or they have some user customized OD settings which cannot be
> overwritten
> -  */
> - if (smu->adev->in_suspend)
> - return 0;
> -
>   ret = smu_cmn_update_table(smu, SMU_TABLE_OVERDRIVE, 0,
> (void *)boot_od_table, false);
>   if (ret) {
>   dev_err(smu->adev->dev, "Failed to get overdrive table!\n");
> @@ -2553,7 +2546,27 @@ static int navi10_set_default_od_settings(struct
> smu_context *smu)
>   navi10_dump_od_table(smu, boot_od_table);
> 
>   memcpy(od_table, boot_od_table, sizeof(OverDriveTable_t));
> - memcpy(user_od_table, boot_od_table, sizeof(OverDriveTable_t));
> +
> + /*
> +  * For S3/S4/Runpm resume, we need to setup those overdrive
> tables again,
> +  * but we have to preserve user defined values in "user_od_table".
> +  */
> + if (!smu->adev->in_suspend) {
> + memcpy(user_od_table, boot_od_table,
> sizeof(OverDriveTable_t));
> + smu->user_dpm_profile.user_od = false;
> + } else if (smu->user_dpm_profile.user_od) {
> + memcpy(&user_od_table_bak, user_od_table,
> sizeof(OverDriveTable_t));
> + memcpy(user_od_table, boot_od_table,
> sizeof(OverDriveTable_t));
> + user_od_table->GfxclkFmin =
> user_od_table_bak.GfxclkFmin;
> + user_od_table->GfxclkFmax =
> user_od_table_bak.GfxclkFmax;
> + user_od_table->UclkFmax = user_od_table_bak.UclkFmax;
> + user_od_table->GfxclkFreq1 =
> user_od_table_bak.GfxclkFreq1;
> + user_od_table->GfxclkVolt1 =
> user_od_table_bak.GfxclkVolt1;
> + user_od_table->GfxclkFreq2 =
> user_od_table_bak.GfxclkFreq2;
> + user_od_table->GfxclkVolt2 =
> user_od_table_bak.GfxclkVolt2;
> + user_od_table->GfxclkFreq3 =
> user_od_table_bak.GfxclkFreq3;
> + user_od_table->GfxclkVolt3 =
> user_od_table_bak.GfxclkVolt3;
> + }
Thing is a little tricky for navi10... 
For navi2x, the vfcurve settings(GfxVfCurve.a, GfxVfCurve.b, GfxVfCurve.c) are 
not configurable by user. We do not expose them to user.
So, we can just load the new vfcurve settings on resuming back without worry 
about overriding user's settings.

Unlike navi2x, user can customize the vfcurve settings(by setting 
GfxclkFreq/GfxVolt pairs) on navi10. More specifically:
- On cold boot, btc was triggered and vfcurve line was calibrated
- Driver calculated the target voltage(via 
navi10_overdrive_get_gfx_clk_base_voltage) for the point 
frequencies(GfxclkFreq1, GfxclkFreq2, GfxclkFreq3) and expose them to user
   - e.g. point1 frequency/voltage:  500Mhz/ 0.75v
- T

RE: [PATCH v2] drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume

[Quan, Evan]

[AMD Official Use Only - General]

Thanks Alex. I probably get the root cause of the issue. It should be related 
with the BTC feature.
- On cold boot, BTC was triggered and GfxVfCurve was calibrated.
   We got VfCurve settings (a).
- On resuming back, BTC will be triggered again and GfxVfCurve will be 
recalibrated.
   VfCurve settings (b) got may be different from those of cold boot. 
   So if to reuse those VfCurve settings (a) got on cold boot, we might got 
some V/f issues.

These can be confirmed by comparing the CustomGfxVfCurve settings got on cold 
boot and resuming.
+   dev_err(smu->adev->dev, "OD: GfxVfCurve: (%d, %d, %d)\n",
+   
od_table->CustomGfxVfCurve.a,
+   
od_table->CustomGfxVfCurve.b,
+   
od_table->CustomGfxVfCurve.c);
Below are some data collected on my nv21 platform and we can see the GfxVfCurve 
settings are different.
- On cold boot: OD: GfxVfCurve: (1046469987, -1089068751, 1066221898)
- On resuming back: OD: GfxVfCurve: (1046393849, -1089130480, 1066199153)

Hi @Błażej Szczygieł,
If you can add some descriptions about the BTC and GfxVfCurve related in the 
patch header/description part, it will be better.
Anyway, the patch is Reviewed-by: Evan Quan 

BR
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Tuesday, March 7, 2023 11:23 PM
> To: Quan, Evan 
> Cc: Błażej Szczygieł ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm/amd/pm: Fix sienna cichlid incorrect OD volage
> after resume
> 
> On Tue, Mar 7, 2023 at 3:23 AM Quan, Evan  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Can you share more background about this? I cannot see how this can
> address incorrect OD voltage issue.
> 
> See https://gitlab.freedesktop.org/drm/amd/-/issues/1897
> The OD settings don't seem to be restored properly on resume.
> 
> Alex
> 
> >
> > BR
> > Evan
> > > -Original Message-
> > > From: amd-gfx  On Behalf Of
> > > Blazej Szczygiel
> > > Sent: Sunday, March 5, 2023 7:45 AM
> > > To: amd-gfx@lists.freedesktop.org
> > > Cc: Błażej Szczygieł 
> > > Subject: [PATCH v2] drm/amd/pm: Fix sienna cichlid incorrect OD
> > > volage after resume
> > >
> > > Always setup overdrive tables after resume. Preserve only some
> > > user-defined settings in user_overdrive_table if they're set.
> > >
> > > Copy restored user_overdrive_table into od_table to get correct
> > > values.
> > >
> > > Signed-off-by: Błażej Szczygieł 
> > > ---
> > >  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 43
> ++
> > > -
> > >  1 file changed, 33 insertions(+), 10 deletions(-)
> > >
> > > diff --git
> a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > > b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > > index 697e98a0a20a..75f18681e984 100644
> > > --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > > +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> > > @@ -2143,16 +2143,9 @@ static int
> > > sienna_cichlid_set_default_od_settings(struct smu_context *smu)
> > >   (OverDriveTable_t *)smu->smu_table.boot_overdrive_table;
> > >   OverDriveTable_t *user_od_table =
> > >   (OverDriveTable_t
> > > *)smu->smu_table.user_overdrive_table;
> > > + OverDriveTable_t user_od_table_bak;
> > >   int ret = 0;
> > >
> > > - /*
> > > -  * For S3/S4/Runpm resume, no need to setup those overdrive
> > > tables again as
> > > -  *   - either they already have the default OD settings got during 
> > > cold
> > > bootup
> > > -  *   - or they have some user customized OD settings which cannot be
> > > overwritten
> > > -  */
> > > - if (smu->adev->in_suspend)
> > > - return 0;
> > > -
> > >   ret = smu_cmn_update_table(smu, SMU_TABLE_OVERDRIVE,
> > >  0, (void *)boot_od_table, false);
> > >   if (ret) {
> > > @@ -2163,7 +2156,23 @@ static int
> > > sienna_cichlid_set_default_od_settings(struct smu_context *smu)
> > >   sienna_cichlid_dump_od_table(smu, boot_od_table);
> > >
> > >   memcpy(od_table, boot_od_table, sizeof(OverDriveTable_t));
> > > - memcpy(user_od_table, boot_od_ta

RE: [PATCH v2] drm/amd/pm: Fix sienna cichlid incorrect OD volage after resume

[Quan, Evan]

[AMD Official Use Only - General]

Can you share more background about this? I cannot see how this can address 
incorrect OD voltage issue.

BR
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> Blazej Szczygiel
> Sent: Sunday, March 5, 2023 7:45 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Błażej Szczygieł 
> Subject: [PATCH v2] drm/amd/pm: Fix sienna cichlid incorrect OD volage after
> resume
> 
> Always setup overdrive tables after resume. Preserve only some
> user-defined settings in user_overdrive_table if they're set.
> 
> Copy restored user_overdrive_table into od_table to get correct
> values.
> 
> Signed-off-by: Błażej Szczygieł 
> ---
>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 43 ++
> -
>  1 file changed, 33 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index 697e98a0a20a..75f18681e984 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -2143,16 +2143,9 @@ static int
> sienna_cichlid_set_default_od_settings(struct smu_context *smu)
>   (OverDriveTable_t *)smu->smu_table.boot_overdrive_table;
>   OverDriveTable_t *user_od_table =
>   (OverDriveTable_t *)smu->smu_table.user_overdrive_table;
> + OverDriveTable_t user_od_table_bak;
>   int ret = 0;
> 
> - /*
> -  * For S3/S4/Runpm resume, no need to setup those overdrive
> tables again as
> -  *   - either they already have the default OD settings got during cold
> bootup
> -  *   - or they have some user customized OD settings which cannot be
> overwritten
> -  */
> - if (smu->adev->in_suspend)
> - return 0;
> -
>   ret = smu_cmn_update_table(smu, SMU_TABLE_OVERDRIVE,
>  0, (void *)boot_od_table, false);
>   if (ret) {
> @@ -2163,7 +2156,23 @@ static int
> sienna_cichlid_set_default_od_settings(struct smu_context *smu)
>   sienna_cichlid_dump_od_table(smu, boot_od_table);
> 
>   memcpy(od_table, boot_od_table, sizeof(OverDriveTable_t));
> - memcpy(user_od_table, boot_od_table, sizeof(OverDriveTable_t));
> +
> + /*
> +  * For S3/S4/Runpm resume, we need to setup those overdrive
> tables again,
> +  * but we have to preserve user defined values in "user_od_table".
> +  */
> + if (!smu->adev->in_suspend) {
> + memcpy(user_od_table, boot_od_table,
> sizeof(OverDriveTable_t));
> + smu->user_dpm_profile.user_od = false;
> + } else if (smu->user_dpm_profile.user_od) {
> + memcpy(&user_od_table_bak, user_od_table,
> sizeof(OverDriveTable_t));
> + memcpy(user_od_table, boot_od_table,
> sizeof(OverDriveTable_t));
> + user_od_table->GfxclkFmin =
> user_od_table_bak.GfxclkFmin;
> + user_od_table->GfxclkFmax =
> user_od_table_bak.GfxclkFmax;
> + user_od_table->UclkFmin = user_od_table_bak.UclkFmin;
> + user_od_table->UclkFmax = user_od_table_bak.UclkFmax;
> + user_od_table->VddGfxOffset =
> user_od_table_bak.VddGfxOffset;
> + }
> 
>   return 0;
>  }
> @@ -2373,6 +2382,20 @@ static int
> sienna_cichlid_od_edit_dpm_table(struct smu_context *smu,
>   return ret;
>  }
> 
> +static int sienna_cichlid_restore_user_od_settings(struct smu_context
> *smu)
> +{
> + struct smu_table_context *table_context = &smu->smu_table;
> + OverDriveTable_t *od_table = table_context->overdrive_table;
> + OverDriveTable_t *user_od_table = table_context-
> >user_overdrive_table;
> + int res;
> +
> + res = smu_v11_0_restore_user_od_settings(smu);
> + if (res == 0)
> + memcpy(od_table, user_od_table,
> sizeof(OverDriveTable_t));
> +
> + return res;
> +}
> +
>  static int sienna_cichlid_run_btc(struct smu_context *smu)
>  {
>   int res;
> @@ -4400,7 +4423,7 @@ static const struct pptable_funcs
> sienna_cichlid_ppt_funcs = {
>   .set_soft_freq_limited_range =
> smu_v11_0_set_soft_freq_limited_range,
>   .set_default_od_settings = sienna_cichlid_set_default_od_settings,
>   .od_edit_dpm_table = sienna_cichlid_od_edit_dpm_table,
> - .restore_user_od_settings = smu_v11_0_restore_user_od_settings,
> + .restore_user_od_settings =
> sienna_cichlid_restore_user_od_settings,
>   .run_btc = sienna_cichlid_run_btc,
>   .set_power_source = smu_v11_0_set_power_source,
>   .get_pp_feature_mask = smu_cmn_get_pp_feature_mask,
> --
> 2.39.2

RE: [PATCH 1/2] drm/amdgpu: fix error checking in amdgpu_read_mm_registers for soc15

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Monday, March 6, 2023 11:54 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: [PATCH 1/2] drm/amdgpu: fix error checking in
> amdgpu_read_mm_registers for soc15
> 
> Properly skip non-existent registers as well.
> 
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2442
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/soc15.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
> b/drivers/gpu/drm/amd/amdgpu/soc15.c
> index 7cd17dda32ce..2eddd7f6cd41 100644
> --- a/drivers/gpu/drm/amd/amdgpu/soc15.c
> +++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
> @@ -439,8 +439,9 @@ static int soc15_read_register(struct amdgpu_device
> *adev, u32 se_num,
>   *value = 0;
>   for (i = 0; i < ARRAY_SIZE(soc15_allowed_read_registers); i++) {
>   en = &soc15_allowed_read_registers[i];
> - if (adev->reg_offset[en->hwip][en->inst] &&
> - reg_offset != (adev->reg_offset[en->hwip][en-
> >inst][en->seg]
> + if (!adev->reg_offset[en->hwip][en->inst])
> + continue;
> + else if (reg_offset != (adev->reg_offset[en->hwip][en-
> >inst][en->seg]
>   + en->reg_offset))
>   continue;
> 
> --
> 2.39.2

RE: [PATCH] drm/amdkfd: fix warning in SVM debug statement

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Tuesday, March 7, 2023 6:43 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: [PATCH] drm/amdkfd: fix warning in SVM debug statement
> 
> Print a long long value.
> 
> In file included
> from ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu_object.h:32,
>  from drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:29:
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c: In function
> ‘svm_migrate_copy_to_vram’:
> ./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgpu.h:35:21: warning:
> format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6
> has type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
>35 | #define pr_fmt(fmt) "amdgpu: " fmt
>   | ^~
> ./include/linux/dynamic_debug.h:223:29: note: in expansion of macro
> ‘pr_fmt’
>   223 | func(&id, ##__VA_ARGS__);   \
>   | ^~~
> ./include/linux/dynamic_debug.h:247:9: note: in expansion of macro
> ‘__dynamic_func_call_cls’
>   247 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func,
> ##__VA_ARGS__)
>   | ^~~
> ./include/linux/dynamic_debug.h:249:9: note: in expansion of macro
> ‘_dynamic_func_call_cls’
>   249 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func,
> ##__VA_ARGS__)
>   | ^~
> ./include/linux/dynamic_debug.h:268:9: note: in expansion of macro
> ‘_dynamic_func_call’
>   268 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
>   | ^~
> ./include/linux/printk.h:581:9: note: in expansion of macro
> ‘dynamic_pr_debug’
>   581 | dynamic_pr_debug(fmt, ##__VA_ARGS__)
>   | ^~~~
> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_migrate.c:302:9: note: in
> expansion of macro ‘pr_debug’
>   302 | pr_debug("svms 0x%p [0x%lx 0x%lx 0x%lx]\n", prange->svms,
> prange->start,
>   | ^~~~
> 
> Fixes: b752374fdf3a ("drm/amdkfd: Fix BO offset for multi-VMA page
> migration")
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> index ad109403b5cc..391da6acb3e5 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
> @@ -299,7 +299,7 @@ svm_migrate_copy_to_vram(struct amdgpu_device
> *adev, struct svm_range *prange,
>   uint64_t i, j;
>   int r;
> 
> - pr_debug("svms 0x%p [0x%lx 0x%lx 0x%lx]\n", prange->svms,
> prange->start,
> + pr_debug("svms 0x%p [0x%lx 0x%lx 0x%llx]\n", prange->svms,
> prange->start,
>prange->last, ttm_res_offset);
> 
>   src = scratch;
> --
> 2.39.2

RE: [PATCH 0/3] enable new capped/uncapped power profiles

[Quan, Evan]

[AMD Official Use Only - General]

Series is reviewed-by: Evan Quan 

> -Original Message-
> From: Yuan, Perry 
> Sent: Friday, February 24, 2023 4:33 PM
> To: Deucher, Alexander ; Quan, Evan
> ; Lazar, Lijo ; Li, Candice
> ; amd-gfx@lists.freedesktop.org
> Cc: Huang, Shimmer ; Liu, Kun
> 
> Subject: [PATCH 0/3] enable new capped/uncapped power profiles
> 
> The patchset will enable the capped and uncapped mode
> 
> This new capped power mode has limit DRAM Thresholds and conditions in
> DF-PState Algorithm based on the workload type set from driver.
> The uncapped mode will reset to normal performance level which has no
> such power limitations.
> 
> Perf Centric Workload (Uncapped)  0
> Power Centric Workload (Capped)   1
> 
> Perry Yuan (3):
>   drm/amdgpu/pm: add capped/uncapped power profile modes
>   drm/amdgpu: map new capped and uncapped mode power profiles for
> Vangogh
>   drm/amdgpu: skip the invalid workload type
> 
>  drivers/gpu/drm/amd/include/kgd_pp_interface.h  | 2 ++
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c  | 2 ++
>  .../drm/amd/pm/swsmu/inc/pmfw_if/smu11_driver_if_vangogh.h  | 4 +++-
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c| 6 --
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c| 4 +++-
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c| 4 +++-
>  drivers/gpu/drm/amd/pm/swsmu/smu_cmn.c  | 4 ++--
>  7 files changed, 19 insertions(+), 7 deletions(-)
> 
> --
> 2.34.1

RE: [PATCH] drm/amdgpu: disable cstate properly for driver reloading scenario

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, March 2, 2023 5:21 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH] drm/amdgpu: disable cstate properly for driver
> reloading scenario
> 
> 
> 
> On 3/2/2023 2:43 PM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Lazar, Lijo 
> >> Sent: Thursday, March 2, 2023 4:28 PM
> >> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander 
> >> Subject: Re: [PATCH] drm/amdgpu: disable cstate properly for driver
> >> reloading scenario
> >>
> >>
> >>
> >> On 3/2/2023 12:28 PM, Evan Quan wrote:
> >>> Gpu reset might be needed during driver reloading. To guard that(gpu
> >>> reset) work, df cstate needs to be disabled properly.
> >>>
> >>> Signed-off-by: Evan Quan 
> >>> Change-Id: I5c074c265c0b08a67b6934ae1ad9aa3fed245461
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
> >>>1 file changed, 9 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> index 51bbeaa1f311..3c854461ef32 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> @@ -2816,6 +2816,15 @@ static int amdgpu_device_ip_fini_early(struct
> >> amdgpu_device *adev)
> >>>   amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
> >>>   amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
> >>>
> >>> + /*
> >>> +  * Get df cstate disabled properly on driver unloading.
> >>> +  * Since on the succeeding driver reloading, gpu reset might
> >>> +  * be required. And cstate disabled is a prerequisite for
> >>> +  * that(gpu reset).
> >>> +  */
> >>> + if (amdgpu_dpm_set_df_cstate(adev, DF_CSTATE_DISALLOW))
> >>> + dev_warn(adev->dev, "Failed to disallow df cstate");
> >>> +
> >>
> >> This looks more like a firmware bug. Driver sends the Unload message to
> FW.
> >> In that case FW should disable all features including C-state.
> > Driver does not send the Unload message. We want PMFM alive and ready
> for handling possible gpu reset on reloading.
> >
> 
> Actually, soc21_need_reset_on_init code itself has a bug. PSP won't get
> unloaded by default on ring destruction. Even if PSP stops, it could just keep
> the heartbeat value as non-zero (just that it won't increment).
> 
> Probably, that needs to be fixed first rather than keeping PMFW alive for a
> reset.
As I remembered, the change(asic reset during reloading) seemed introduced to 
address some sriov issues.
@Deucher, Alexander might share more backgrounds about this.
To be honest, I'm not a fan of this(perform asic reset during reloading).

Evan
> 
> Thanks,
> Lijo
> 
> > BR
> > Evan
> >>
> >> Thanks,
> >> Lijo
> >>
> >>>   amdgpu_amdkfd_suspend(adev, false);
> >>>
> >>>   /* Workaroud for ASICs need to disable SMC first */

RE: [PATCH] gpu: amd/pm: mark symbols static where possible for smu11

[Quan, Evan]

[AMD Official Use Only - General]

Thanks. But I think there was already a patch from Kun Liu to address this 
issue.
https://lists.freedesktop.org/archives/amd-gfx/2023-March/090029.html

BR
Evan
> -Original Message-
> From: Jeff Pang 
> Sent: Thursday, March 2, 2023 5:16 PM
> To: Quan, Evan 
> Cc: amd-gfx@lists.freedesktop.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; Jeff Pang 
> Subject: [PATCH] gpu: amd/pm: mark symbols static where possible for
> smu11
> 
> I get one warning when building kernel with -Werror=missing-prototypes :
> 
> drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu11/vangogh_ppt.c:1600:5:
> error: no previous prototype for ‘vangogh_set_apu_thermal_limit’
> [-Werror=missing-prototypes]
> int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t limit)
> 
> In fact, this function don't need a declaration due to it's only used in the 
> file
> which they are.
> So this patch marks the function with 'static'.
> 
> Signed-off-by: Jeff Pang 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 016d5621e0b3..24046af60933 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -1597,7 +1597,7 @@ static int vangogh_get_apu_thermal_limit(struct
> smu_context *smu, uint32_t *limi
> 0, limit);
>  }
> 
> -int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t
> limit)
> +static int vangogh_set_apu_thermal_limit(struct smu_context *smu,
> +uint32_t limit)
>  {
>   return smu_cmn_send_smc_msg_with_param(smu,
> 
> SMU_MSG_SetReducedThermalLimit,
> --
> 2.34.1

RE: [PATCH] drm/amdgpu: disable cstate properly for driver reloading scenario

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Thursday, March 2, 2023 4:28 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH] drm/amdgpu: disable cstate properly for driver
> reloading scenario
> 
> 
> 
> On 3/2/2023 12:28 PM, Evan Quan wrote:
> > Gpu reset might be needed during driver reloading. To guard that(gpu
> > reset) work, df cstate needs to be disabled properly.
> >
> > Signed-off-by: Evan Quan 
> > Change-Id: I5c074c265c0b08a67b6934ae1ad9aa3fed245461
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 +
> >   1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 51bbeaa1f311..3c854461ef32 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -2816,6 +2816,15 @@ static int amdgpu_device_ip_fini_early(struct
> amdgpu_device *adev)
> > amdgpu_device_set_pg_state(adev, AMD_PG_STATE_UNGATE);
> > amdgpu_device_set_cg_state(adev, AMD_CG_STATE_UNGATE);
> >
> > +   /*
> > +* Get df cstate disabled properly on driver unloading.
> > +* Since on the succeeding driver reloading, gpu reset might
> > +* be required. And cstate disabled is a prerequisite for
> > +* that(gpu reset).
> > +*/
> > +   if (amdgpu_dpm_set_df_cstate(adev, DF_CSTATE_DISALLOW))
> > +   dev_warn(adev->dev, "Failed to disallow df cstate");
> > +
> 
> This looks more like a firmware bug. Driver sends the Unload message to FW.
> In that case FW should disable all features including C-state.
Driver does not send the Unload message. We want PMFM alive and ready for 
handling possible gpu reset on reloading.

BR
Evan
> 
> Thanks,
> Lijo
> 
> > amdgpu_amdkfd_suspend(adev, false);
> >
> > /* Workaroud for ASICs need to disable SMC first */

RE: [PATCH] drm/amdgpu: fix no previous prototype warning

[Quan, Evan]

[AMD Official Use Only - General]

Please add proper tag as instructed. Other than this , the patch is 
Reviewed-by: Evan Quan 
"If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303010827.c2n0ybgt-...@intel.com/";

BR
Evan
> -Original Message-
> From: Kun Liu 
> Sent: Wednesday, March 1, 2023 10:42 AM
> To: amd-gfx@lists.freedesktop.org; Quan, Evan 
> Cc: Liang, Richard qi ; Deucher, Alexander
> ; Liu, Kun 
> Subject: [PATCH] drm/amdgpu: fix no previous prototype warning
> 
> add static prefix for vangogh_set_apu_thermal_limit function
> 
> Signed-off-by: Kun Liu 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index 016d5621e0b3..24046af60933 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -1597,7 +1597,7 @@ static int vangogh_get_apu_thermal_limit(struct
> smu_context *smu, uint32_t *limi
> 0, limit);
>  }
> 
> -int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t
> limit)
> +static int vangogh_set_apu_thermal_limit(struct smu_context *smu,
> uint32_t limit)
>  {
>   return smu_cmn_send_smc_msg_with_param(smu,
> 
> SMU_MSG_SetReducedThermalLimit,
> --
> 2.25.1

RE: [PATCH v2 3/3] drm/amd: Add special handling for system s0ix state w/ dGPUs

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Mario Limonciello
> Sent: Tuesday, February 28, 2023 12:43 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Peter Kopec ; Limonciello, Mario
> 
> Subject: [PATCH v2 3/3] drm/amd: Add special handling for system s0ix state
> w/ dGPUs
> 
> With dGPUs that support BACO or BOCO we want them to go into those
> states when the system goes to s2idle.  Detect that the system will
> be targeting this state and force the call into runtime suspend.
> 
> If the runtime suspend call fails for any reason, then fallback to
> standard suspend flow.
The "standard suspend" means here is normal s2idle flow. Right?
> 
> Signed-off-by: Mario Limonciello 
> ---
> v1->v2:
>  * New patch
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c |  3 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 12 +++-
>  2 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index 711f2a1bf525..7c3c6380135a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -1073,8 +1073,7 @@ bool amdgpu_acpi_should_gpu_reset(struct
> amdgpu_device *adev)
>   */
>  bool amdgpu_acpi_is_s0ix_active(struct amdgpu_device *adev)
>  {
> - if (!(adev->flags & AMD_IS_APU) ||
> - (pm_suspend_target_state != PM_SUSPEND_TO_IDLE))
> + if (pm_suspend_target_state != PM_SUSPEND_TO_IDLE)
>   return false;
> 
>   if (adev->asic_type < CHIP_RAVEN)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 750984517192..acc032c4c250 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2415,8 +2415,18 @@ static int amdgpu_pmops_suspend(struct device
> *dev)
>   struct drm_device *drm_dev = dev_get_drvdata(dev);
>   struct amdgpu_device *adev = drm_to_adev(drm_dev);
> 
> - if (amdgpu_acpi_is_s0ix_active(adev))
> + if (amdgpu_acpi_is_s0ix_active(adev)) {
> + /* try to explicitly enter runtime suspend for s2idle on
> BACO/BOCO */
> + if (dev_pm_test_driver_flags(drm_dev->dev,
> DPM_FLAG_SMART_SUSPEND)) {
> + int ret;
> +
> + ret = pm_runtime_suspend(dev);
> + if (!ret)
> + return 0;
"ret" seems redundant and can be dropped.

BR
Evan
> + DRM_WARN("failed to enter runtime suspend,
> running system suspend: %d\n", ret);
> + }
>   adev->in_s0ix = true;
> + }
>   else if (amdgpu_acpi_is_s3_active(adev))
>   adev->in_s3 = true;
>   if (!adev->in_s0ix && !adev->in_s3)
> --
> 2.34.1

RE: [PATCH v2 0/3] Adjust dGPU handling for BACO

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Mario Limonciello
> Sent: Tuesday, February 28, 2023 12:43 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Peter Kopec ; Limonciello, Mario
> 
> Subject: [PATCH v2 0/3] Adjust dGPU handling for BACO
> 
> This series adjusts the handling for dGPUs when the system is going into
> s2idle.  The intent is to match the following truth table below:
> 
> +---+--+--
> +-+
> |   | s2idle (no FADT) | s2idle (FADT)
> | deep
> |
> +---+--+--
> +-+
> | APU Prepare   | 0| 0
> | 0   |
> | APU Suspend   | Run  | Run  
> | Run
> |
> | BACO dGPU Prepare | 1 if suspended   | 1 if suspended   
> | 1
> if suspended  |
> | BACO dGPU Suspend | Runtime suspend if prepare was 0 | Runtime
> suspend if prepare was 0 | S3 suspend if prepare was 0 |
> | BOCO dGPU Prepare | 1| 1
> | 1 if suspended
> |
For BOCO Prepare, it should be also "1 if suspsended" instead of "1" for s2idle 
per patch1. 
Do I miss anything?

BR
Evan
> | BOCO dGPU Suspend | Runtime suspend if prepare was 0 | Runtime
> suspend if prepare was 0 | S3 suspend if prepare was 0 |
> +---+--+--
> +-+
> 
> That is BACO and BOCO are handled very similarly when system is doing
> s2idle.
> 
> v1->v2:
>  * Rework flags and flow
>  * Try to do runtime suspend first, and if it fails do system suspend
> 
> Mario Limonciello (3):
>   drm/amd: Allow dGPUs that support BACO to use smart suspend
>   drm/amd: Don't always set s3 for dGPUs in all sleep modes
>   drm/amd: Add special handling for system s0ix state w/ dGPUs
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 11 +++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c  | 44 +++-
> 
>  2 files changed, 34 insertions(+), 21 deletions(-)
> 
> --
> 2.34.1

RE: [PATCH 1/3] drm/amd: Allow dGPUs that support BACO to use smart suspend

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Mario Limonciello
> Sent: Tuesday, February 21, 2023 4:16 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Peter Kopec ; Limonciello, Mario
> 
> Subject: [PATCH 1/3] drm/amd: Allow dGPUs that support BACO to use smart
> suspend
> 
> If a dGPU is already runtime suspended using BACO, there is no point
> to waking it up to run regular suspend callbacks.
Not quite sure about this.. Since the expectations for runtime suspend(over 
BACO) and regular suspend seem different:
- For runtime suspending over BACO, part of the chip(SMU, NBIO) is still alive.
- For regular suspend(suspend to ram), the whole chip is expected to be powered 
down.
That means the resuming sequences for them might be slightly different. Not 
sure whether that will cause some problems.

BR
Evan
> 
> Cc: Peter Kopec 
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 1f6d93dc3d72..c3d3a042946d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2187,8 +2187,9 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>   /* only need to skip on ATPX */
>   if (amdgpu_device_supports_px(ddev))
>   dev_pm_set_driver_flags(ddev->dev,
> DPM_FLAG_NO_DIRECT_COMPLETE);
> - /* we want direct complete for BOCO */
> - if (amdgpu_device_supports_boco(ddev))
> + /* we want direct complete for BOCO and for BACO */
> + if (amdgpu_device_supports_boco(ddev) ||
> + amdgpu_device_supports_baco(ddev))
>   dev_pm_set_driver_flags(ddev->dev,
> DPM_FLAG_SMART_PREPARE |
> 
>   DPM_FLAG_SMART_SUSPEND |
> 
>   DPM_FLAG_MAY_SKIP_RESUME);
> @@ -2389,7 +2390,8 @@ static int amdgpu_pmops_prepare(struct device
> *dev)
>   /* Return a positive number here so
>* DPM_FLAG_SMART_SUSPEND works properly
>*/
> - if (amdgpu_device_supports_boco(drm_dev))
> + if (amdgpu_device_supports_boco(drm_dev) ||
> + amdgpu_device_supports_baco(drm_dev))
>   return pm_runtime_suspended(dev);
> 
>   /* if we will not support s3 or s2i for the device
> --
> 2.34.1

RE: [PATCH 3/3] drm/amd: Don't always set s3 for dGPUs in all sleep modes

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: amd-gfx  On Behalf Of
> Mario Limonciello
> Sent: Tuesday, February 21, 2023 4:16 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Peter Kopec ; Limonciello, Mario
> 
> Subject: [PATCH 3/3] drm/amd: Don't always set s3 for dGPUs in all sleep
> modes
> 
> dGPUs that will be using BACO or BOCO shouldn't be put into S3
> when the system is being put into s2idle.
Will this break regular suspend to ram scenario? I mean
- For s2idle scenario, amdgpu_pmops_prepare will be called. And for this 
scenario, it is expected dgpu using BACO or BOCO to be not put into S3. Right?
- For regular s2ram scenario, amdgpu_pmops_prepare will also get called. Then 
dgpu using BACO or BOCO will be not put into S3 either?

BR
Evan
> 
> Cc: Peter Kopec 
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index 25e902077caf..5c69116bc883 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -1038,8 +1038,13 @@ void amdgpu_acpi_detect(void)
>   */
>  bool amdgpu_acpi_is_s3_active(struct amdgpu_device *adev)
>  {
> - return !(adev->flags & AMD_IS_APU) ||
> - (pm_suspend_target_state == PM_SUSPEND_MEM);
> + if (pm_suspend_target_state == PM_SUSPEND_MEM)
> + return true;
> + if (adev->flags & AMD_IS_APU)
> + return false;
> + return !amdgpu_device_supports_baco(&adev->ddev) &&
> + !amdgpu_device_supports_boco(&adev->ddev);
> +
>  }
> 
>  /**
> --
> 2.34.1

RE: [PATCH 1/2] drm/amdgpu: added a sysfs interface for thermal throttling

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: kunliu13 
> Sent: Tuesday, February 14, 2023 3:54 PM
> To: Limonciello, Mario ; Liang, Richard qi
> ; Yuan, Perry ; amd-
> g...@lists.freedesktop.org
> Cc: Deucher, Alexander ; Du, Xiaojian
> ; Quan, Evan ; Liu, Kun
> 
> Subject: [PATCH 1/2] drm/amdgpu: added a sysfs interface for thermal
> throttling
> 
> added a sysfs interface for thermal throttling, then userspace can get/update
> thermal limit
> 
> Jira ID: SWDEV-354511
[Quan, Evan] Please drop this internal link. Other than this, the patch is 
Reviewed-by: Evan Quan 

Evan
> Signed-off-by: Kun Liu 
> 
> Change-Id: I9948cb8966b731d2d74d7aad87cbcdc840dd34c8
> ---
>  .../gpu/drm/amd/include/kgd_pp_interface.h|  2 +
>  drivers/gpu/drm/amd/pm/amdgpu_dpm.c   | 28 +++
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c| 76
> +++
>  drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h   |  3 +
>  drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 24 ++
>  drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 12 +++
>  6 files changed, 145 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> index f3d64c78f..8394464ea 100644
> --- a/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> +++ b/drivers/gpu/drm/amd/include/kgd_pp_interface.h
> @@ -331,6 +331,8 @@ struct amd_pm_funcs {
>   int (*get_mclk_od)(void *handle);
>   int (*set_mclk_od)(void *handle, uint32_t value);
>   int (*read_sensor)(void *handle, int idx, void *value, int *size);
> + int (*get_apu_thermal_limit)(void *handle, uint32_t *limit);
> + int (*set_apu_thermal_limit)(void *handle, uint32_t limit);
>   enum amd_dpm_forced_level (*get_performance_level)(void
> *handle);
>   enum amd_pm_state_type (*get_current_power_state)(void
> *handle);
>   int (*get_fan_speed_rpm)(void *handle, uint32_t *rpm);
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> index 1b300c569..d9a9cf189 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_dpm.c
> @@ -438,6 +438,34 @@ int amdgpu_dpm_read_sensor(struct
> amdgpu_device *adev, enum amd_pp_sensors senso
>   return ret;
>  }
> 
> +int amdgpu_dpm_get_apu_thermal_limit(struct amdgpu_device *adev,
> uint32_t *limit)
> +{
> + const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
> + int ret = -EINVAL;
> +
> + if (pp_funcs && pp_funcs->get_apu_thermal_limit) {
> + mutex_lock(&adev->pm.mutex);
> + ret = pp_funcs->get_apu_thermal_limit(adev-
> >powerplay.pp_handle, limit);
> + mutex_unlock(&adev->pm.mutex);
> + }
> +
> + return ret;
> +}
> +
> +int amdgpu_dpm_set_apu_thermal_limit(struct amdgpu_device *adev,
> uint32_t limit)
> +{
> + const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
> + int ret = -EINVAL;
> +
> + if (pp_funcs && pp_funcs->set_apu_thermal_limit) {
> + mutex_lock(&adev->pm.mutex);
> + ret = pp_funcs->set_apu_thermal_limit(adev-
> >powerplay.pp_handle, limit);
> + mutex_unlock(&adev->pm.mutex);
> + }
> +
> + return ret;
> +}
> +
>  void amdgpu_dpm_compute_clocks(struct amdgpu_device *adev)
>  {
>   const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index 236657eec..99b249e55 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -1685,6 +1685,81 @@ static ssize_t
> amdgpu_set_thermal_throttling_logging(struct device *dev,
>   return count;
>  }
> 
> +/**
> + * DOC: apu_thermal_cap
> + *
> + * The amdgpu driver provides a sysfs API for retrieving/updating thermal
> + * limit temperature in millidegrees Celsius
> + *
> + * Reading back the file shows you core limit value
> + *
> + * Writing an integer to the file, sets a new thermal limit. The value
> + * should be between 0 and 100. If the value is less than 0 or greater
> + * than 100, then the write request will be ignored.
> + */
> +static ssize_t amdgpu_get_apu_thermal_cap(struct device *dev,
> +  struct device_attribute *attr,
> +  char *buf)
> +{
> + int ret, size = 0;
> + u32 limit;
> + struct drm_device *ddev = dev_get_drvdata(dev);
> + struct amdgpu_device *adev = drm_to_adev(ddev);
> +
> + ret = pm_runtime_get_sync(ddev-&

RE: [PATCH 2/2] drm/amdgpu: added a sysfs interface for thermal throttling

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: kunliu13 
> Sent: Tuesday, February 14, 2023 4:03 PM
> To: Limonciello, Mario ; Liang, Richard qi
> ; Yuan, Perry ; amd-
> g...@lists.freedesktop.org
> Cc: Deucher, Alexander ; Du, Xiaojian
> ; Quan, Evan ; Liu, Kun
> 
> Subject: [PATCH 2/2] drm/amdgpu: added a sysfs interface for thermal
> throttling
> 
> implement apu_thermal_cap r/w callback for vangogh
> 
> Jira ID: SWDEV-354511
[Quan, Evan] Please drop this internal link.
> Signed-off-by: Kun Liu 
> ---
>  .../gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c  | 23
> +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> index cb10c7e31..d211b1dfe 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/vangogh_ppt.c
> @@ -1590,6 +1590,27 @@ static int vangogh_read_sensor(struct
> smu_context *smu,
>   return ret;
>  }
> 
> +static int vangogh_get_apu_thermal_limit(struct smu_context *smu,
> uint32_t *limit)
> +{
> + int ret = -EINVAL;
> +
> + ret = smu_cmn_send_smc_msg_with_param(smu,
> +   SMU_MSG_GetThermalLimit,
> +   0, limit);
> + return ret;
[Quan, Evan] "ret" here and below in vangogh_set_apu_thermal_limit seem 
unnecessary.
Other that those, the patch is reviewed-by: Evan Quan 

Evan
> +}
> +
> +int vangogh_set_apu_thermal_limit(struct smu_context *smu, uint32_t
> limit)
> +{
> + int ret = -EINVAL;
> +
> + ret = smu_cmn_send_smc_msg_with_param(smu,
> +
> SMU_MSG_SetReducedThermalLimit,
> +   limit, NULL);
> + return ret;
> +}
> +
> +
>  static int vangogh_set_watermarks_table(struct smu_context *smu,
>  struct pp_smu_wm_range_sets
> *clock_ranges)
>  {
> @@ -2425,6 +2446,8 @@ static const struct pptable_funcs
> vangogh_ppt_funcs = {
>   .dpm_set_jpeg_enable = vangogh_dpm_set_jpeg_enable,
>   .is_dpm_running = vangogh_is_dpm_running,
>   .read_sensor = vangogh_read_sensor,
> + .get_apu_thermal_limit = vangogh_get_apu_thermal_limit,
> + .set_apu_thermal_limit = vangogh_set_apu_thermal_limit,
>   .get_enabled_mask = smu_cmn_get_enabled_mask,
>   .get_pp_feature_mask = smu_cmn_get_pp_feature_mask,
>   .set_watermarks_table = vangogh_set_watermarks_table,
> --
> 2.25.1

RE: [PATCH] drm/amd/amdgpu: fix warining during suspend

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-and-tested-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Jack
> Xiao
> Sent: Monday, February 13, 2023 6:52 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Xiao, Jack ; jfale...@redhat.com
> Subject: [PATCH] drm/amd/amdgpu: fix warining during suspend
> 
> Freeing memory was warned during suspend.
> Move the self test out of suspend.
> 
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=2151825
> Cc: jfale...@redhat.com
> Signed-off-by: Jack Xiao 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
>  drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a10b627c8357..3842e7e62eda 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -4270,6 +4270,9 @@ int amdgpu_device_resume(struct drm_device
> *dev, bool fbcon)
>   }
>   adev->in_suspend = false;
> 
> + if (adev->enable_mes)
> + amdgpu_mes_self_test(adev);
> +
>   if (amdgpu_acpi_smart_shift_update(dev, AMDGPU_SS_DEV_D0))
>   DRM_WARN("smart shift update failed\n");
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> index 62cdd2113135..5826eac270d7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mes_v11_0.c
> @@ -1284,7 +1284,7 @@ static int mes_v11_0_late_init(void *handle)
>   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
> 
>   /* it's only intended for use in mes_self_test case, not for s0ix and
> reset */
> - if (!amdgpu_in_reset(adev) && !adev->in_s0ix &&
> + if (!amdgpu_in_reset(adev) && !adev->in_s0ix && !adev-
> >in_suspend &&
>   (adev->ip_versions[GC_HWIP][0] != IP_VERSION(11, 0, 3)))
>   amdgpu_mes_self_test(adev);
> 
> --
> 2.37.3

RE: [PATCH] drm/amd/amdgpu: implement mode2 reset on smu_v13_0_10

[Quan, Evan]

&adev->pm.mutex);
> +
> + ret = pp_funcs->asic_reset_enable_gfx_features(pp_handle);
> +
> + mutex_unlock(&adev->pm.mutex);
> +
> + return ret;
> +}
> +
>  int amdgpu_dpm_baco_reset(struct amdgpu_device *adev)
>  {
>   const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
> diff --git a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> index 485522cb0238..ff2ebf786bb0 100644
> --- a/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> +++ b/drivers/gpu/drm/amd/pm/inc/amdgpu_dpm.h
> @@ -387,6 +387,7 @@ int amdgpu_dpm_switch_power_profile(struct
> amdgpu_device *adev,
>  int amdgpu_dpm_baco_reset(struct amdgpu_device *adev);
> 
>  int amdgpu_dpm_mode2_reset(struct amdgpu_device *adev);
> +int amdgpu_dpm_enable_gfx_features(struct amdgpu_device *adev);
> 
>  bool amdgpu_dpm_is_baco_supported(struct amdgpu_device *adev);
>  bool amdgpu_dpm_is_maco_supported(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index f08698493502..0fe926bdc18a 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -2874,6 +2874,23 @@ static int smu_mode2_reset(void *handle)
>   return ret;
>  }
> 
> +static int smu_enable_gfx_features(void *handle)
> +{
> + struct smu_context *smu = handle;
> + int ret = 0;
> +
> + if (!smu->pm_enabled)
> + return -EOPNOTSUPP;
> +
> + if (smu->ppt_funcs->enable_gfx_features)
> + ret = smu->ppt_funcs->enable_gfx_features(smu);
> +
> + if (ret)
> + dev_err(smu->adev->dev, "enable gfx features failed!\n");
> +
> + return ret;
> +}
> +
>  static int smu_get_max_sustainable_clocks_by_dc(void *handle,
>   struct
> pp_smu_nv_clock_table *max_clocks)
>  {
> @@ -3059,6 +3076,7 @@ static const struct amd_pm_funcs
> swsmu_pm_funcs = {
>   .get_ppfeature_status = smu_sys_get_pp_feature_mask,
>   .set_ppfeature_status = smu_sys_set_pp_feature_mask,
>   .asic_reset_mode_2= smu_mode2_reset,
> + .asic_reset_enable_gfx_features   = smu_enable_gfx_features,
>   .set_df_cstate= smu_set_df_cstate,
>   .set_xgmi_pstate  = smu_set_xgmi_pstate,
>   .get_gpu_metrics  = smu_sys_get_gpu_metrics,
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> index f5f0b2f3c610..1f65048a5c33 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h
> @@ -1202,6 +1202,7 @@ struct pptable_funcs {
>* IPs reset varies by asic.
>*/
>   int (*mode2_reset)(struct smu_context *smu);
> + int (*enable_gfx_features)(struct smu_context *smu);
[Quan, Evan] Might better to add some descriptions for the new API as for other 
APIs.
Either way the patch is acked-by: Evan Quan 
> 
>   /**
>* @get_dpm_ultimate_freq: Get the hard frequency range of a
> clock
> diff --git
> a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
> index 8b8266890a10..10cff75b44d5 100644
> ---
> a/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
> +++
> b/drivers/gpu/drm/amd/pm/swsmu/inc/pmfw_if/smu_v13_0_0_ppsmc.h
> @@ -94,6 +94,7 @@
>  //Resets
>  #define PPSMC_MSG_PrepareMp1ForUnload0x2E
>  #define PPSMC_MSG_Mode1Reset 0x2F
> +#define PPSMC_MSG_Mode2Reset  0x4F
> 
>  //Set SystemVirtual DramAddrHigh
>  #define PPSMC_MSG_SetSystemVirtualDramAddrHigh   0x30
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> index 4180c71d930f..96f6c2db955b 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> +++ b/drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h
> @@ -242,7 +242,8 @@
>   __SMU_DUMMY_MAP(LogGfxOffResidency),\
>   __SMU_DUMMY_MAP(SetNumBadMemoryPagesRetired),
>   \
> 
>   __SMU_DUMMY_MAP(SetBadMemoryPagesRetiredFlagsPerChann
> el), \
> - __SMU_DUMMY_MAP(AllowGpo),
> + __SMU_DUMMY_MAP(AllowGpo),  \
> + __SMU_DUMMY_MAP(Mode2Reset),
> 
>  #undef __SMU_DUMMY_MAP
>  #define __SMU_DUMMY_MAP(type)SMU_MSG_##type
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index 8b06a673e77c..44dd88bb3935 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -138,6 +138,7 @@ static struct cmn2asic_msg_mapping
> smu_v13_0_0_message_map[SMU_MSG_MAX_COUNT] =
>   MSG_MAP(GetPptLimit,
>   PPSMC_MSG_GetPptLimit, 0),
>   MSG_MAP(NotifyPowerSource,
>   PPSMC_MSG_NotifyPowerSource,   0),
>   MSG_MAP(Mode1Reset,
>   PPSMC_MSG_Mode1Reset,  0),
> + MSG_MAP(Mode2Reset,
>   PPSMC_MSG_Mode2Reset,  0),
>   MSG_MAP(PrepareMp1ForUnload,
>   PPSMC_MSG_PrepareMp1ForUnload, 0),
>   MSG_MAP(DFCstateControl,
>   PPSMC_MSG_SetExternalClientDfCstateAllow, 0),
>   MSG_MAP(ArmD3,  PPSMC_MSG_ArmD3,
> 0),
> @@ -1957,6 +1958,30 @@ static int smu_v13_0_0_mode1_reset(struct
> smu_context *smu)
>   return ret;
>  }
> 
> +static int smu_v13_0_0_mode2_reset(struct smu_context *smu)
> +{
> + int ret;
> + struct amdgpu_device *adev = smu->adev;
> +
> + if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 10))
> + ret = smu_cmn_send_smc_msg(smu,
> SMU_MSG_Mode2Reset, NULL);
> + else
> + return -EOPNOTSUPP;
> +
> + return ret;
> +}
> +
> +static int smu_v13_0_0_enable_gfx_features(struct smu_context *smu)
> +{
> + struct amdgpu_device *adev = smu->adev;
> +
> + if (adev->ip_versions[MP1_HWIP][0] == IP_VERSION(13, 0, 10))
> + return smu_cmn_send_smc_msg_with_param(smu,
> SMU_MSG_EnableAllSmuFeatures,
> +
>  FEATURE_PWR_GFX, NULL);
> + else
> + return -EOPNOTSUPP;
> +}
> +
>  static void smu_v13_0_0_set_smu_mailbox_registers(struct smu_context
> *smu)
>  {
>   struct amdgpu_device *adev = smu->adev;
> @@ -2073,6 +2098,8 @@ static const struct pptable_funcs
> smu_v13_0_0_ppt_funcs = {
>   .baco_exit = smu_v13_0_0_baco_exit,
>   .mode1_reset_is_support =
> smu_v13_0_0_is_mode1_reset_supported,
>   .mode1_reset = smu_v13_0_0_mode1_reset,
> + .mode2_reset = smu_v13_0_0_mode2_reset,
> + .enable_gfx_features = smu_v13_0_0_enable_gfx_features,
>   .set_mp1_state = smu_v13_0_0_set_mp1_state,
>   .set_df_cstate = smu_v13_0_0_set_df_cstate,
>   .send_hbm_bad_pages_num =
> smu_v13_0_0_smu_send_bad_mem_page_num,
> --
> 2.25.1

RE: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is unavailable

[Quan, Evan]

[AMD Official Use Only - General]

Hi Jack,

Are you trying to fix the call trace popped up on resuming below?
It seems mes created some bo for its self test and freed it up later at the 
final stage of the resuming process.
All these happened before the in_suspend flag cleared. And that triggered the 
call trace.
Is my understanding correct?

[74084.799260] WARNING: CPU: 2 PID: 2891 at 
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:425 amdgpu_bo_free_kernel+0xfc/0x110 
[amdgpu]
[74084.811019] Modules linked in: nls_iso8859_1 amdgpu(OE) iommu_v2 gpu_sched 
drm_buddy drm_ttm_helper ttm drm_display_helper drm_kms_helper i2c_algo_bit 
fb_sys_fops syscopyarea sysfillrect sysimgblt snd_sm
[74084.811042]  ip_tables x_tables autofs4 hid_logitech_hidpp hid_logitech_dj 
hid_generic e1000e usbhid ptp uas hid video i2c_i801 ahci pps_core crc32_pclmul 
i2c_smbus usb_storage libahci wmi
[74084.914519] CPU: 2 PID: 2891 Comm: kworker/u16:38 Tainted: GW IOE
  6.0.0-custom #1
[74084.923146] Hardware name: ASUS System Product Name/PRIME Z390-A, BIOS 2004 
11/02/2021
[74084.931074] Workqueue: events_unbound async_run_entry_fn
[74084.936393] RIP: 0010:amdgpu_bo_free_kernel+0xfc/0x110 [amdgpu]
[74084.942422] Code: 00 4d 85 ed 74 08 49 c7 45 00 00 00 00 00 4d 85 e4 74 08 
49 c7 04 24 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc <0f> 0b e9 
39 ff ff ff 3d 00 fe ff ff 0f 85 75 96 47 00 ebf
[74084.961199] RSP: :bed6812ebb90 EFLAGS: 00010202
[74084.966435] RAX:  RBX: bed6812ebc50 RCX: 
[74084.973578] RDX: bed6812ebc70 RSI: bed6812ebc60 RDI: bed6812ebc50
[74084.980725] RBP: bed6812ebbb8 R08:  R09: 01ff
[74084.987869] R10: bed6812ebb40 R11:  R12: bed6812ebc70
[74084.995015] R13: bed6812ebc60 R14: 963a2945cc00 R15: 9639c7da5630
[74085.002160] FS:  () GS:963d1dc8() 
knlGS:
[74085.010262] CS:  0010 DS:  ES:  CR0: 80050033
[74085.016016] CR2:  CR3: 000377c0a001 CR4: 003706e0
[74085.023164] DR0:  DR1:  DR2: 
[74085.030307] DR3:  DR6: fffe0ff0 DR7: 0400
[74085.037453] Call Trace:
[74085.039911]  
[74085.042023]  amdgpu_mes_self_test+0x385/0x460 [amdgpu]
[74085.047293]  mes_v11_0_late_init+0x44/0x50 [amdgpu]
[74085.052291]  amdgpu_device_ip_late_init+0x50/0x270 [amdgpu]
[74085.058032]  amdgpu_device_resume+0xb0/0x2d0 [amdgpu]
[74085.063187]  amdgpu_pmops_resume+0x37/0x70 [amdgpu]
[74085.068162]  pci_pm_resume+0x68/0x100
[74085.071836]  ? pci_legacy_resume+0x80/0x80
[74085.075943]  dpm_run_callback+0x4c/0x160
[74085.079873]  device_resume+0xad/0x210
[74085.083546]  async_resume+0x1e/0x40
[74085.087046]  async_run_entry_fn+0x30/0x120
[74085.091152]  process_one_work+0x21a/0x3f0
[74085.095173]  worker_thread+0x50/0x3e0
[74085.098845]  ? process_one_work+0x3f0/0x3f0
[74085.103039]  kthread+0xfa/0x130
[74085.106189]  ? kthread_complete_and_exit+0x20/0x20
[74085.110993]  ret_from_fork+0x1f/0x30
[74085.114576]  
[74085.116773] ---[ end trace  ]---

BR
Evan
From: amd-gfx  On Behalf Of Christian 
König
Sent: Monday, February 6, 2023 5:00 PM
To: Xiao, Jack ; Koenig, Christian 
; amd-gfx@lists.freedesktop.org; Deucher, Alexander 

Subject: Re: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is 
unavailable

Am 06.02.23 um 09:28 schrieb Xiao, Jack:

[AMD Official Use Only - General]

  >> >> It's simply not allowed to free up 
resources during suspend since those can't be acquired again during resume.
  >> The in_suspend flag is set at the beginning of 
suspend and unset at the end of resume. It can't filter the case you mentioned.

   Why not? This is exactly what it should do.

[Jack] If freeing up resources during resume, it should not hit the issue you 
described. But only checking in_suspend flag would take these cases as warning.

No, once more: Freeing up or allocating resources between suspend and resume is 
illegal!

If you free up a resource during resume you should absolutely hit that, this is 
intentional!

Regards,
Christian.


Regards,
Jack

From: Koenig, Christian 

Sent: Monday, February 6, 2023 4:06 PM
To: Xiao, Jack ; Christian König 
; 
amd-gfx@lists.freedesktop.org; Deucher, 
Alexander 
Subject: Re: [PATCH] drm/amdgpu: only WARN freeing buffers when DMA is 
unavailable

Am 06.02.23 um 08:23 schrieb Xiao, Jack:

[AMD Official Use Only - General]

>> Nope, that is not related to any hw state.

can use other flag.

>> It's simply not allowed to free up resources during suspend since those 
>> can't be acquired again during resume.
The in_suspend flag is set at th

RE: gpu_metrics does not provide 'current_gfxclk', 'current_uclk', 'average_cpu_power' & 'temperature_core' on AMD Ryzen 7000 CPU

[Quan, Evan]

[AMD Official Use Only - General]

For some members, "0" is a valid value. 
Thus "0x" is used instead to tell the output is invalid/unsupported.

BR
Evan
> -Original Message-
> From: amd-gfx  On Behalf Of
> sfrcorne
> Sent: Wednesday, February 8, 2023 7:12 AM
> To: Alex Deucher 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: gpu_metrics does not provide 'current_gfxclk', 'current_uclk',
> 'average_cpu_power' & 'temperature_core' on AMD Ryzen 7000 CPU
> 
> Dear Alex,
> 
> If current_gfxclk is not supported for my CPU, then using
> average_gfxclk_frequency instead is indeed the best solution in my opinion.
> I will try to get a fix merged for my CPU in Mangohud.
> 
> On a side note: you mentioned that unsupported fields would be 0 but I
> don't think this is correct. In the Linux kernel/driver there is a line of 
> code
> that first set all values to 0xFF by a memset() and then populates the
> supported fields.
> 
> see
> "https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/pm/s
> wsmu/smu_cmn.c#L999": memset(header, 0xFF, structure_size);
> 
> The value of the unsupported uint16_t fields thus should be 0x (or 65535
> in decimal). This is also what I get when reading the gpu_metrics file. I just
> wanted to mention this in case someone reads this in the Archive.
> 
> Anyway, thank you for your help!
> 
> Kind regards,
> sfrcorne
> 
> --- Original Message ---
> On Tuesday, February 7th, 2023 at 05:05, Alex Deucher
>  wrote:
> 
> 
> > On Mon, Feb 6, 2023 at 5:48 PM sfrcorne sfrco...@protonmail.com wrote:
> >
> > > Dear Alex,
> > >
> > > First of all, thank you for your response. Personally, I use a Ryzen 5 
> > > 7600X
> however people with a Ryzen 9 7900X are also reporting this issue. The
> relevant bug report in Mangohud can be found here:
> "https://github.com/flightlessmango/MangoHud/issues/868";.
> > >
> > > I looked around a bit in both the Mangohud source code and the Linux
> kernel source code.
> > >
> > > (Mangohud source): From what I understand, Mangohud looks for a file
> "/sys/class/drm/card*/device/gpu_metrics". If this file exists (and it does
> exists on my machine), it tries to read this file and extract the relevant GPU
> data (and in case of an APU also the CPU data) from it (these are the values I
> was talking about in my previous mail). When the file
> "/sys/class/drm/card*/device/gpu_metrics" exists, it will not use the data
> provided by hwmon (/sys/class/hwmon/hwmon*/*).
> > >
> > > (Linux kernel): The gpu_metrics file contains different data, depending
> on what version is used. All valid versions can be found in the source code:
> "https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/includ
> e/kgd_pp_interface.h#L725". For my CPU/APU the 'gpu_metrics_v2_1'
> structure is used (I tested this by reading the gpu_metrics file myself).
> Furthermore, I think that for my case, this structure is set by the function
> "https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/pm/s
> wsmu/smu13/smu_v13_0_5_ppt.c#L459" but I am not completely sure
> about this.
> >
> >
> > The metrics provided by the SMU firmware varies from asic to asic.
> > For things that are not supported by the metrics table for a
> > particular asic, those fields would be 0. You can see what metrics are
> > supported for your asic in smu_v13_0_5_get_gpu_metrics() as that
> > function populates the supported fields from the firmware to the
> > common structure. current_gfxclk is not supported in your asic, but
> > average_gfxclk_frequency is. So you'd want to use whichever field is
> > available for a particular asic in Mangohud.
> >
> > > Lastly, I am not familiar with umr. I assume that you are referring to
> "https://gitlab.freedesktop.org/tomstdenis/umr";? If I find some time this
> weekend, then I will look into this some more.
> >
> >
> > Yes, that is the right link. umr uses the same interface as mangohud,
> > so you should see the same data.
> >
> > Alex
> >
> > > Kind regards,
> > > sfrcorne
> > >
> > > --- Original Message ---
> > > On Monday, February 6th, 2023 at 22:22, Alex Deucher
> alexdeuc...@gmail.com wrote:
> > >
> > > > On Mon, Feb 6, 2023 at 9:22 AM sfrcorne sfrco...@protonmail.com
> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I hope this is the correct place to ask my question. I was not sure 
> > > > > if I
> should have opened a new issue on Gitlab or send an email here, since I
> don't know know whether this is a bug or intended behaviour.
> > > > >
> > > > > The question is about the new AMD Ryzen 7000 CPU's. These new
> CPU's have an iGPU and consequently provide a gpu_metrics file for
> monitoring the GPU/CPU (APU?). This file is used by programs like
> Mangohud, that try to read (among other values) the following 4 values:
> > > > > - current_gfxclk
> > > > > - current_uclk
> > > > > - average_cpu_power
> > > > > - temperature_core
> > > > > However it appears that on AMD Ryzen 7000 CPU's these 4 values are
> no

RE: [PATCH] drm/amdgpu/gmc11: disable AGP aperture again

[Quan, Evan]

[AMD Official Use Only - General]

Settings for gfxhub_v3_0_3.c seem missing.

Evan
> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Thursday, February 9, 2023 12:25 PM
> To: Zhang, Hawking 
> Cc: Deucher, Alexander ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdgpu/gmc11: disable AGP aperture again
> 
> Actually, nevermind, I found the bug.  New patch on the way.
> 
> Alex
> 
> On Wed, Feb 8, 2023 at 9:52 PM Zhang, Hawking 
> wrote:
> >
> > [AMD Official Use Only - General]
> >
> > Reviewed-by: Hawking Zhang 
> >
> > Regards,
> > Hawking
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Alex Deucher
> > Sent: Thursday, February 9, 2023 05:24
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander 
> > Subject: [PATCH] drm/amdgpu/gmc11: disable AGP aperture again
> >
> > It seems not all of the issues with SDMA firmware have been resolved
> leading to spurious GPU page faults on some variants.
> >
> > Signed-off-by: Alex Deucher 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c  | 7 +++
> >  drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c| 1 -
> >  drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c   | 7 +++
> >  drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c | 5 +++--
> > drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c | 6 +++---
> >  5 files changed, 12 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
> > index 7c069010ca9a..fa42d1907dfa 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfxhub_v3_0.c
> > @@ -151,11 +151,10 @@ static void
> gfxhub_v3_0_init_system_aperture_regs(struct amdgpu_device *adev)  {
> > uint64_t value;
> >
> > -   /* Program the AGP BAR */
> > +   /* Disable AGP. */
> > WREG32_SOC15(GC, 0, regGCMC_VM_AGP_BASE, 0);
> > -   WREG32_SOC15(GC, 0, regGCMC_VM_AGP_BOT, adev-
> >gmc.agp_start >> 24);
> > -   WREG32_SOC15(GC, 0, regGCMC_VM_AGP_TOP, adev-
> >gmc.agp_end >> 24);
> > -
> > +   WREG32_SOC15(GC, 0, regGCMC_VM_AGP_TOP, 0);
> > +   WREG32_SOC15(GC, 0, regGCMC_VM_AGP_BOT, 0x00FF);
> >
> > /* Program the system aperture low logical page number. */
> > WREG32_SOC15(GC, 0,
> regGCMC_VM_SYSTEM_APERTURE_LOW_ADDR,
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
> > b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
> > index 0a31a341aa43..5e0018fe7e7d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
> > @@ -673,7 +673,6 @@ static void gmc_v11_0_vram_gtt_location(struct
> > amdgpu_device *adev,
> >
> > amdgpu_gmc_vram_location(adev, &adev->gmc, base);
> > amdgpu_gmc_gart_location(adev, mc);
> > -   amdgpu_gmc_agp_location(adev, mc);
> >
> > /* base offset of vram pages */
> > if (amdgpu_sriov_vf(adev))
> > diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
> > b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
> > index 923fc09bc8fc..ae9cd1a4cfee 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0.c
> > @@ -177,11 +177,10 @@ static void
> mmhub_v3_0_init_system_aperture_regs(struct amdgpu_device *adev)
> >  * these regs, and they will be programed at host.
> >  * so skip programing these regs.
> >  */
> > -   /* Program the AGP BAR */
> > +   /* Disable AGP. */
> > WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BASE, 0);
> > -   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BOT, adev-
> >gmc.agp_start >> 24);
> > -   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_TOP, adev-
> >gmc.agp_end >> 24);
> > -
> > +   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_TOP, 0);
> > +   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BOT, 0x00FF);
> > /* Program the system aperture low logical page number. */
> > WREG32_SOC15(MMHUB, 0,
> regMMMC_VM_SYSTEM_APERTURE_LOW_ADDR,
> >  adev->gmc.vram_start >> 18); diff --git
> > a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
> > b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
> > index c8d478f2afdc..fb2f0eb72f69 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_1.c
> > @@ -173,8 +173,9 @@ static void
> > mmhub_v3_0_1_init_system_aperture_regs(struct amdgpu_device *adev)
> >
> > /* Program the AGP BAR */
> > WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BASE, 0);
> > -   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BOT, adev-
> >gmc.agp_start >> 24);
> > -   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_TOP, adev-
> >gmc.agp_end >> 24);
> > +   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_TOP, 0);
> > +   WREG32_SOC15(MMHUB, 0, regMMMC_VM_AGP_BOT, 0x00FF);
> > +
> >
> > /*
> >  * the new L1 policy will block SRIOV guest from writing diff
> > --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c
> > b/drivers/gpu/drm/amd/amdgpu/mmhub_v3_0_2.c
> > index 51

RE: [PATCH] drm/amd/pm/smu7: move variables to where they are used

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: Deucher, Alexander 
> Sent: Tuesday, February 7, 2023 1:05 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: [PATCH] drm/amd/pm/smu7: move variables to where they are
> used
> 
> Move variable declarations to where they are used.  Fixes
> a segfault on smu7 V0 structures where some tables don't
> exist.
> 
> Cc: Evan Quan 
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2388
> Fixes: 711d3c39503b ("drm/amd/pm: fulfill powerplay peak profiling mode
> shader/memory clock settings")
> Signed-off-by: Alex Deucher 
> ---
>  .../gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c| 14 --
> 
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
> b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
> index 89fc32318d80..e10cc5e7928e 100644
> --- a/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
> +++ b/drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c
> @@ -1504,12 +1504,6 @@ static void
> smu7_populate_umdpstate_clocks(struct pp_hwmgr *hwmgr)
>  {
>   struct smu7_hwmgr *data = (struct smu7_hwmgr *)(hwmgr-
> >backend);
>   struct smu7_dpm_table *golden_dpm_table = &data-
> >golden_dpm_table;
> - struct phm_clock_voltage_dependency_table
> *vddc_dependency_on_sclk =
> - hwmgr->dyn_state.vddc_dependency_on_sclk;
> - struct phm_ppt_v1_information *table_info =
> - (struct phm_ppt_v1_information *)(hwmgr-
> >pptable);
> - struct phm_ppt_v1_clock_voltage_dependency_table
> *vdd_dep_on_sclk =
> - table_info->vdd_dep_on_sclk;
>   int32_t tmp_sclk, count, percentage;
> 
>   if (golden_dpm_table->mclk_table.count == 1) {
> @@ -1524,6 +1518,9 @@ static void
> smu7_populate_umdpstate_clocks(struct pp_hwmgr *hwmgr)
>   tmp_sclk = hwmgr->pstate_mclk * percentage / 100;
> 
>   if (hwmgr->pp_table_version == PP_TABLE_V0) {
> + struct phm_clock_voltage_dependency_table
> *vddc_dependency_on_sclk =
> + hwmgr->dyn_state.vddc_dependency_on_sclk;
> +
>   for (count = vddc_dependency_on_sclk->count - 1; count >=
> 0; count--) {
>   if (tmp_sclk >= vddc_dependency_on_sclk-
> >entries[count].clk) {
>   hwmgr->pstate_sclk =
> vddc_dependency_on_sclk->entries[count].clk;
> @@ -1536,6 +1533,11 @@ static void
> smu7_populate_umdpstate_clocks(struct pp_hwmgr *hwmgr)
>   hwmgr->pstate_sclk_peak =
>   vddc_dependency_on_sclk-
> >entries[vddc_dependency_on_sclk->count - 1].clk;
>   } else if (hwmgr->pp_table_version == PP_TABLE_V1) {
> + struct phm_ppt_v1_information *table_info =
> + (struct phm_ppt_v1_information *)(hwmgr-
> >pptable);
> + struct phm_ppt_v1_clock_voltage_dependency_table
> *vdd_dep_on_sclk =
> + table_info->vdd_dep_on_sclk;
> +
>   for (count = vdd_dep_on_sclk->count - 1; count >= 0; count--)
> {
>   if (tmp_sclk >= vdd_dep_on_sclk->entries[count].clk)
> {
>   hwmgr->pstate_sclk = vdd_dep_on_sclk-
> >entries[count].clk;
> --
> 2.39.1

RE: [PATCH 2/2] drm/amdgpu/pm: update hwmon power documentation

[Quan, Evan]

[AMD Official Use Only - General]

Reviewed-by: Evan Quan 

> -Original Message-
> From: amd-gfx  On Behalf Of Alex
> Deucher
> Sent: Friday, January 13, 2023 12:25 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: [PATCH 2/2] drm/amdgpu/pm: update hwmon power
> documentation
> 
> Power reporting is socket power.  On APUs this includes the CPU.  Update
> the documentation to clarify this.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index 236657eece47..76b9ec64ca50 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -3059,7 +3059,7 @@ static ssize_t
> amdgpu_hwmon_show_mclk_label(struct device *dev,
>   *
>   * hwmon interfaces for GPU power:
>   *
> - * - power1_average: average power used by the GPU in microWatts
> + * - power1_average: average power used by the SoC in microWatts.  On
> APUs this includes the CPU.
>   *
>   * - power1_cap_min: minimum cap supported in microWatts
>   *
> --
> 2.39.0

RE: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks addition

[Quan, Evan]

[AMD Official Use Only - General]

Series is reviewed-by: Evan Quan 

> -Original Message-
> From: Deepak R Varma 
> Sent: Sunday, January 15, 2023 3:16 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; David
> Airlie ; Daniel Vetter ; amd-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> ker...@vger.kernel.org
> Cc: Saurabh Singh Sengar ; Praveen Kumar
> 
> Subject: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks
> addition
> 
> The patch series proposes usage of bitwise or "|" operator for addition of
> bitmasks instead of using numerial additions. The former is quicker and
> cleaner.
> 
> The proposed change is compile tested.
> 
> Deepak R Varma (3):
>   drm/amd/pm/powerplay/smumgr: use bitwise or for addition
>   drm/amd/pm/powerplay/hwmgr: use bitwise or for bitmasks addition
>   drm/amd/pm/powerplay/smumgr/ci: use bitwise or for bitmasks addition
> 
>  drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c  | 8 ---
> -
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c  | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 2 +-
>  drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c   | 2 +-
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> --
> 2.34.1
> 
> 

RE: [PATCH 8/8] drm/amd/pm: drop the support for manual fan speed setting on SMU13.0.7

[Quan, Evan]

[AMD Official Use Only - General]

Hi Matt,

The problem with the approach(removal of interface functions from the 
ppt_funcs) is:
1. If to drop support for some sysfs interface, you need to know the internal 
implementation details to mask out the corresponding function.
That's not straightforward and might be not an easy job for new comer.
2. Sometimes the missing of some interfaces is unintentional. It needs to be 
added instead of being treated as unsupported.
3. The removal of the interface cannot update the sysfs file permission 
together. That means the sysfs file might be still shown as writable while
actually the setting is not supported at all.
The patch series try to address these in a simple and straightforward way.

Regarding the manual fan speed setting issue targeted by this patch, the SCPM 
feature of the new SMU13 asics prevents us from toggling the fan control 
feature from auto to manual.
Without that, the manual fan speed setting to some specific RPM/PWM is not 
possible.
About the capability in the OD table you mentioned, it might be a different 
issue.
Since as I know, the capability the OD table provided is to change the 
minimum/maximum fan speed limit.
That should be not affected by the SCPM and relevant.

BR
Evan
> -Original Message-
> From: Matt Coffin 
> Sent: Tuesday, January 10, 2023 9:57 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Quan, Evan ; Lazar, Lijo 
> Subject: Re: [PATCH 8/8] drm/amd/pm: drop the support for manual fan
> speed setting on SMU13.0.7
> 
> On 1/9/23 23:48, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> > We need these to address the fan speed setting failure reported for the
> new SMU13 asics.
> My opinion shouldn't matter much given sparseness of activity, but, despite
> his... short tonality, I agree with Lijo's assessment there.
> 
> As someone less familiar with the code base, the use of "multiple sources of
> truth" contributes to making it harder to understand and ramp up with.
> 
> As for the sysfs fan control issue itself, this won't really "fix" the issue, 
> but
> rather just remove write permissions from the hwmon files (if my
> testing+understanding is right), so it wouldn't seem to be a hyper-critical
> deliverable to me as a random outsider looking in (despite being effected by
> the issue personally). Even with that interface removed, there isn't another
> way to control the "auto" fans, as the FW reports it doesn't support that
> capability in the OD table, and ignores anything set therein for that purpose.
> Hopefully that's temporary until FW gets fixed?
> 
> I also think the behavior of the other proposed solution (removal of interface
> functions from the ppt_funcs), is objectively a better experience w/r/t
> outcome. If the functions are NULL, then the hwmon device files go away
> *completely*, instead of just being masked from write permission, which
> would make the message clearer to the end user that it's not an error, but an
> actual lack of functionality.
> 
> Cheers, sorry I couldn't help, but wanted to at least have something come of
> the last few days I spent implmenting OD on SMU13 for nothing!
> 
> ~Matt

RE: [PATCH 8/8] drm/amd/pm: drop the support for manual fan speed setting on SMU13.0.7

[Quan, Evan]

[AMD Official Use Only - General]

Anyone else can help to review this patch series?
We need these to address the fan speed setting failure reported for the new 
SMU13 asics.
@Deucher, Alexander ?

Evan
> -Original Message-
> From: Quan, Evan 
> Sent: Thursday, January 5, 2023 11:23 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: [PATCH 8/8] drm/amd/pm: drop the support for manual fan speed
> setting on SMU13.0.7
> 
> Due to lack of support from PMFW.
> 
> Signed-off-by: Evan Quan 
> Change-Id: I8439e72b95ad2fdf8cfdf1edc4d9c8af58109dc3
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 5 +
>  1 file changed, 5 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 3608540f2034..c7fa203ec7e8 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
> @@ -1736,4 +1736,9 @@ void smu_v13_0_7_set_ppt_funcs(struct
> smu_context *smu)
> 
> BIT_ULL(AMD_SYSFS_IF_PP_DPM_DCEFCLK_BIT) |
> 
> BIT_ULL(AMD_SYSFS_IF_PP_SCLK_OD_BIT) |
> 
> BIT_ULL(AMD_SYSFS_IF_PP_MCLK_OD_BIT));
> + /* Drop the support for manual fan speed(RPM and PWM) setting */
> + smu->adev-
> >pm.hwmon_if_attr_mode[AMD_HWMON_IF_PWM1_ENABLE_BIT] &=
> ~S_IWUSR;
> + smu->adev-
> >pm.hwmon_if_attr_mode[AMD_HWMON_IF_PWM1_BIT] &= ~S_IWUSR;
> + smu->adev-
> >pm.hwmon_if_attr_mode[AMD_HWMON_IF_FAN1_ENABLE_BIT] &=
> ~S_IWUSR;
> + smu->adev-
> >pm.hwmon_if_attr_mode[AMD_HWMON_IF_FAN1_TARGET_BIT] &=
> ~S_IWUSR;
>  }
> --
> 2.34.1

RE: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces support

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Monday, January 9, 2023 6:52 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces
> support
> 
> 
> 
> On 1/9/2023 2:27 PM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Lazar, Lijo 
> >> Sent: Monday, January 9, 2023 11:28 AM
> >> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander 
> >> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >> interfaces support
> >>
> >>
> >>
> >> On 1/9/2023 7:42 AM, Quan, Evan wrote:
> >>> [AMD Official Use Only - General]
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Lazar, Lijo 
> >>>> Sent: Friday, January 6, 2023 6:01 PM
> >>>> To: Quan, Evan ; amd-
> g...@lists.freedesktop.org
> >>>> Cc: Deucher, Alexander 
> >>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >>>> interfaces support
> >>>>
> >>>>
> >>>>
> >>>> On 1/6/2023 2:14 PM, Quan, Evan wrote:
> >>>>> [AMD Official Use Only - General]
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Lazar, Lijo 
> >>>>>> Sent: Friday, January 6, 2023 11:55 AM
> >>>>>> To: Quan, Evan ; amd-
> >> g...@lists.freedesktop.org
> >>>>>> Cc: Deucher, Alexander 
> >>>>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >>>>>> interfaces support
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/6/2023 7:34 AM, Quan, Evan wrote:
> >>>>>>> [AMD Official Use Only - General]
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -Original Message-
> >>>>>>>> From: Lazar, Lijo 
> >>>>>>>> Sent: Thursday, January 5, 2023 9:58 PM
> >>>>>>>> To: Quan, Evan ; amd-
> >>>> g...@lists.freedesktop.org
> >>>>>>>> Cc: Deucher, Alexander 
> >>>>>>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for
> >>>>>>>> sysfs interfaces support
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 1/5/2023 8:52 AM, Evan Quan wrote:
> >>>>>>>>> Make the code more clean and readable with no real logics
> change.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Evan Quan 
> >>>>>>>>> Change-Id: I21c879fa9abad9f6da3b5289adf3124950d2f4eb
> >>>>>>>>> ---
> >>>>>>>>>   drivers/gpu/drm/amd/pm/amdgpu_pm.c | 200
> >> ++--
> >>>> 
> >>>>>> ---
> >>>>>>>> --
> >>>>>>>>>   1 file changed, 98 insertions(+), 102 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>>>> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>>>> index fb6a7d45693a..c69db29eea24 100644
> >>>>>>>>> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>>>> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>>>> @@ -2006,9 +2006,6 @@ static int default_attr_update(struct
> >>>>>>>> amdgpu_device *adev, struct amdgpu_device_
> >>>>>>>>>uint32_t mask, enum
> >>>> amdgpu_device_attr_states
> >>>>>>>> *states)
> >>>>>>>>>   {
> >>>>>>>>> struct device_attribute *dev_attr = &attr->dev_attr;
> >>>>>>>>> -   uint32_t mp1_ver = adev->ip_versions[MP1_HWIP][0];
> >>>>>>>>> - 

RE: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces support

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Monday, January 9, 2023 11:28 AM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces
> support
> 
> 
> 
> On 1/9/2023 7:42 AM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Lazar, Lijo 
> >> Sent: Friday, January 6, 2023 6:01 PM
> >> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander 
> >> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >> interfaces support
> >>
> >>
> >>
> >> On 1/6/2023 2:14 PM, Quan, Evan wrote:
> >>> [AMD Official Use Only - General]
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Lazar, Lijo 
> >>>> Sent: Friday, January 6, 2023 11:55 AM
> >>>> To: Quan, Evan ; amd-
> g...@lists.freedesktop.org
> >>>> Cc: Deucher, Alexander 
> >>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >>>> interfaces support
> >>>>
> >>>>
> >>>>
> >>>> On 1/6/2023 7:34 AM, Quan, Evan wrote:
> >>>>> [AMD Official Use Only - General]
> >>>>>
> >>>>>
> >>>>>
> >>>>>> -Original Message-
> >>>>>> From: Lazar, Lijo 
> >>>>>> Sent: Thursday, January 5, 2023 9:58 PM
> >>>>>> To: Quan, Evan ; amd-
> >> g...@lists.freedesktop.org
> >>>>>> Cc: Deucher, Alexander 
> >>>>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >>>>>> interfaces support
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/5/2023 8:52 AM, Evan Quan wrote:
> >>>>>>> Make the code more clean and readable with no real logics change.
> >>>>>>>
> >>>>>>> Signed-off-by: Evan Quan 
> >>>>>>> Change-Id: I21c879fa9abad9f6da3b5289adf3124950d2f4eb
> >>>>>>> ---
> >>>>>>>  drivers/gpu/drm/amd/pm/amdgpu_pm.c | 200
> ++--
> >> 
> >>>> ---
> >>>>>> --
> >>>>>>>  1 file changed, 98 insertions(+), 102 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>> index fb6a7d45693a..c69db29eea24 100644
> >>>>>>> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>>>> @@ -2006,9 +2006,6 @@ static int default_attr_update(struct
> >>>>>> amdgpu_device *adev, struct amdgpu_device_
> >>>>>>>  uint32_t mask, enum
> >> amdgpu_device_attr_states
> >>>>>> *states)
> >>>>>>>  {
> >>>>>>>   struct device_attribute *dev_attr = &attr->dev_attr;
> >>>>>>> - uint32_t mp1_ver = adev->ip_versions[MP1_HWIP][0];
> >>>>>>> - uint32_t gc_ver = adev->ip_versions[GC_HWIP][0];
> >>>>>>> - const char *attr_name = dev_attr->attr.name;
> >>>>>>>
> >>>>>>>   if (!(attr->flags & mask) ||
> >>>>>>> !(AMD_SYSFS_IF_BITMASK(attr->if_bit) &
> >>>>>>> adev->pm.sysfs_if_supported))  { @@ -2016,112 +2013,14 @@
> static
> >>>>>>> adev->int
> >>>>>> default_attr_update(struct amdgpu_device *adev, struct
> >>>> amdgpu_device_
> >>>>>>>   return 0;
> >>>>>>>   }
> >>>>>>>
> >>>>>>> -#define DEVICE_ATTR_IS(_name)(!strcmp(attr_name,
> >> #_name))
> >>>>>>> -
> >>>>>>> - if (DEVICE_ATTR_IS(pp_dpm_socclk)) {
> >>>>>>> - if (gc_ver < IP_VERSION(9, 0, 0))
> >>>>>>> - 

RE: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces support

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Friday, January 6, 2023 6:01 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces
> support
> 
> 
> 
> On 1/6/2023 2:14 PM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Lazar, Lijo 
> >> Sent: Friday, January 6, 2023 11:55 AM
> >> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander 
> >> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >> interfaces support
> >>
> >>
> >>
> >> On 1/6/2023 7:34 AM, Quan, Evan wrote:
> >>> [AMD Official Use Only - General]
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: Lazar, Lijo 
> >>>> Sent: Thursday, January 5, 2023 9:58 PM
> >>>> To: Quan, Evan ; amd-
> g...@lists.freedesktop.org
> >>>> Cc: Deucher, Alexander 
> >>>> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >>>> interfaces support
> >>>>
> >>>>
> >>>>
> >>>> On 1/5/2023 8:52 AM, Evan Quan wrote:
> >>>>> Make the code more clean and readable with no real logics change.
> >>>>>
> >>>>> Signed-off-by: Evan Quan 
> >>>>> Change-Id: I21c879fa9abad9f6da3b5289adf3124950d2f4eb
> >>>>> ---
> >>>>> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 200 ++--
> 
> >> ---
> >>>> --
> >>>>> 1 file changed, 98 insertions(+), 102 deletions(-)
> >>>>>
> >>>>> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>> index fb6a7d45693a..c69db29eea24 100644
> >>>>> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>>>> @@ -2006,9 +2006,6 @@ static int default_attr_update(struct
> >>>> amdgpu_device *adev, struct amdgpu_device_
> >>>>>uint32_t mask, enum
> amdgpu_device_attr_states
> >>>> *states)
> >>>>> {
> >>>>> struct device_attribute *dev_attr = &attr->dev_attr;
> >>>>> -   uint32_t mp1_ver = adev->ip_versions[MP1_HWIP][0];
> >>>>> -   uint32_t gc_ver = adev->ip_versions[GC_HWIP][0];
> >>>>> -   const char *attr_name = dev_attr->attr.name;
> >>>>>
> >>>>> if (!(attr->flags & mask) ||
> >>>>>   !(AMD_SYSFS_IF_BITMASK(attr->if_bit) &
> >>>>> adev->pm.sysfs_if_supported))  { @@ -2016,112 +2013,14 @@ static
> >>>>> adev->int
> >>>> default_attr_update(struct amdgpu_device *adev, struct
> >> amdgpu_device_
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>> -#define DEVICE_ATTR_IS(_name)  (!strcmp(attr_name,
> #_name))
> >>>>> -
> >>>>> -   if (DEVICE_ATTR_IS(pp_dpm_socclk)) {
> >>>>> -   if (gc_ver < IP_VERSION(9, 0, 0))
> >>>>> -   *states = ATTR_STATE_UNSUPPORTED;
> >>>>> -   } else if (DEVICE_ATTR_IS(pp_dpm_dcefclk)) {
> >>>>> -   if (gc_ver < IP_VERSION(9, 0, 0) ||
> >>>>> -   gc_ver == IP_VERSION(9, 4, 1) ||
> >>>>> -   gc_ver == IP_VERSION(9, 4, 2))
> >>>>> -   *states = ATTR_STATE_UNSUPPORTED;
> >>>>> -   } else if (DEVICE_ATTR_IS(pp_dpm_fclk)) {
> >>>>> -   if (mp1_ver < IP_VERSION(10, 0, 0))
> >>>>> -   *states = ATTR_STATE_UNSUPPORTED;
> >>>>> -   } else if (DEVICE_ATTR_IS(pp_od_clk_voltage)) {
> >>>>> -   *states = ATTR_STATE_UNSUPPORTED;
> >>>>> -   if (amdgpu_dpm_is_overdrive_supported(adev))
> >>>>> -   *states = ATTR_STATE_SUPPORTED;
> >>>>> -   } else if (DEVICE_ATTR_I

RE: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces support

[Quan, Evan]

[AMD Official Use Only - General]



> -Original Message-
> From: Lazar, Lijo 
> Sent: Friday, January 6, 2023 11:55 AM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander 
> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs interfaces
> support
> 
> 
> 
> On 1/6/2023 7:34 AM, Quan, Evan wrote:
> > [AMD Official Use Only - General]
> >
> >
> >
> >> -Original Message-
> >> From: Lazar, Lijo 
> >> Sent: Thursday, January 5, 2023 9:58 PM
> >> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> >> Cc: Deucher, Alexander 
> >> Subject: Re: [PATCH 2/8] drm/amd/pm: refine the checks for sysfs
> >> interfaces support
> >>
> >>
> >>
> >> On 1/5/2023 8:52 AM, Evan Quan wrote:
> >>> Make the code more clean and readable with no real logics change.
> >>>
> >>> Signed-off-by: Evan Quan 
> >>> Change-Id: I21c879fa9abad9f6da3b5289adf3124950d2f4eb
> >>> ---
> >>>drivers/gpu/drm/amd/pm/amdgpu_pm.c | 200 ++--
> ---
> >> --
> >>>1 file changed, 98 insertions(+), 102 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>> index fb6a7d45693a..c69db29eea24 100644
> >>> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> >>> @@ -2006,9 +2006,6 @@ static int default_attr_update(struct
> >> amdgpu_device *adev, struct amdgpu_device_
> >>>  uint32_t mask, enum 
> >>> amdgpu_device_attr_states
> >> *states)
> >>>{
> >>>   struct device_attribute *dev_attr = &attr->dev_attr;
> >>> - uint32_t mp1_ver = adev->ip_versions[MP1_HWIP][0];
> >>> - uint32_t gc_ver = adev->ip_versions[GC_HWIP][0];
> >>> - const char *attr_name = dev_attr->attr.name;
> >>>
> >>>   if (!(attr->flags & mask) ||
> >>> !(AMD_SYSFS_IF_BITMASK(attr->if_bit) &
> >>> adev->pm.sysfs_if_supported))  { @@ -2016,112 +2013,14 @@ static int
> >> default_attr_update(struct amdgpu_device *adev, struct
> amdgpu_device_
> >>>   return 0;
> >>>   }
> >>>
> >>> -#define DEVICE_ATTR_IS(_name)(!strcmp(attr_name, #_name))
> >>> -
> >>> - if (DEVICE_ATTR_IS(pp_dpm_socclk)) {
> >>> - if (gc_ver < IP_VERSION(9, 0, 0))
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(pp_dpm_dcefclk)) {
> >>> - if (gc_ver < IP_VERSION(9, 0, 0) ||
> >>> - gc_ver == IP_VERSION(9, 4, 1) ||
> >>> - gc_ver == IP_VERSION(9, 4, 2))
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(pp_dpm_fclk)) {
> >>> - if (mp1_ver < IP_VERSION(10, 0, 0))
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(pp_od_clk_voltage)) {
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - if (amdgpu_dpm_is_overdrive_supported(adev))
> >>> - *states = ATTR_STATE_SUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(mem_busy_percent)) {
> >>> - if (adev->flags & AMD_IS_APU || gc_ver == IP_VERSION(9, 0,
> >> 1))
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(pcie_bw)) {
> >>> - /* PCIe Perf counters won't work on APU nodes */
> >>> - if (adev->flags & AMD_IS_APU)
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - } else if (DEVICE_ATTR_IS(unique_id)) {
> >>> - switch (gc_ver) {
> >>> - case IP_VERSION(9, 0, 1):
> >>> - case IP_VERSION(9, 4, 0):
> >>> - case IP_VERSION(9, 4, 1):
> >>> - case IP_VERSION(9, 4, 2):
> >>> - case IP_VERSION(10, 3, 0):
> >>> - case IP_VERSION(11, 0, 0):
> >>> - *states = ATTR_STATE_SUPPORTED;
> >>> - break;
> >>> - default:
> >>> - *states = ATTR_STATE_UNSUPPORTED;
> >>> - }
> >>