From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Xinhui.Pan@amd.com, Patil.Reddy@amd.com,
basavaraj.natikar@amd.com, dri-devel@lists.freedesktop.org,
jikos@kernel.org, amd-gfx@lists.freedesktop.org,
platform-driver-x86@vger.kernel.org, markgross@kernel.org,
Hans de Goede <hdegoede@redhat.com>,
benjamin.tissoires@redhat.com, mario.limonciello@amd.com,
daniel@ffwll.ch, linux-input@vger.kernel.org,
alexander.deucher@amd.com, airlied@gmail.com,
christian.koenig@amd.com
Subject: Re: [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary
Date: Wed, 27 Sep 2023 15:19:08 +0300 (EEST) [thread overview]
Message-ID: <18feb3c4-e8c4-9767-48a-7e3ef1c9cc@linux.intel.com> (raw)
In-Reply-To: <20230922175056.244940-5-Shyam-sundar.S-k@amd.com>
On Fri, 22 Sep 2023, Shyam Sundar S K wrote:
> PMF Policy binary is a encrypted and signed binary that will be part
> of the BIOS. PMF driver via the ACPI interface checks the existence
> of Smart PC bit. If the advertised bit is found, PMF driver walks
> the acpi namespace to find out the policy binary size and the address
> which has to be passed to the TA during the TA init sequence.
>
> The policy binary is comprised of inputs (or the events) and outputs
> (or the actions). With the PMF ecosystem, OEMs generate the policy
> binary (or could be multiple binaries) that contains a supported set
> of inputs and outputs which could be specifically carved out for each
> usage segment (or for each user also) that could influence the system
> behavior either by enriching the user experience or/and boost/throttle
> power limits.
>
> Once the TA init command succeeds, the PMF driver sends the changing
> events in the current environment to the TA for a constant sampling
> frequency time (the event here could be a lid close or open) and
> if the policy binary has corresponding action built within it, the
> TA sends the action for it in the subsequent enact command.
>
> If the inputs sent to the TA has no output defined in the policy
> binary generated by OEMs, there will be no action to be performed
> by the PMF driver.
>
> Example policies:
>
> 1) if slider is performance ; set the SPL to 40W
> Here PMF driver registers with the platform profile interface and
> when the slider position is changed, PMF driver lets the TA know
> about this. TA sends back an action to update the Sustained
> Power Limit (SPL). PMF driver updates this limit via the PMFW mailbox.
>
> 2) if user_away ; then lock the system
> Here PMF driver hooks to the AMD SFH driver to know the user presence
> and send the inputs to TA and if the condition is met, the TA sends
> the action of locking the system. PMF driver generates a uevent and
> based on the udev rule in the userland the system gets locked with
> systemctl.
>
> The intent here is to provide the OEM's to make a policy to lock the
> system when the user is away ; but the userland can make a choice to
> ignore it.
>
> and so on.
>
> The OEMs will have an utility to create numerous such policies and
> the policies shall be reviewed by AMD before signing and encrypting
> them. Policies are shared between operating systems to have seemless user
> experience.
>
> Since all this action has to happen via the "amdtee" driver, currently
> there is no caller for it in the kernel which can load the amdtee driver.
> Without amdtee driver loading onto the system the "tee" calls shall fail
> from the PMF driver. Hence an explicit "request_module" has been added
> to address this.
>
> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> ---
> +struct pmf_action_table {
> + unsigned long spl; /* in mW */
> + unsigned long sppt; /* in mW */
> + unsigned long sppt_apuonly; /* in mW */
> + unsigned long fppt; /* in mW */
> + unsigned long stt_minlimit; /* in mW */
> + unsigned long stt_skintemp_apu; /* in C */
> + unsigned long stt_skintemp_hs2; /* in C */
> +};
> +static void amd_pmf_apply_policies(struct amd_pmf_dev *dev, struct ta_pmf_enact_result *out)
> +{
> + u32 val;
> + int idx;
> +
> + for (idx = 0; idx < out->actions_count; idx++) {
> + val = out->actions_list[idx].value;
> + switch (out->actions_list[idx].action_index) {
> + case PMF_POLICY_SPL:
> + if (dev->prev_data->spl != val) {
> + amd_pmf_send_cmd(dev, SET_SPL, false, val, NULL);
> + dev_dbg(dev->dev, "update SPL : %d\n", val);
The %d does not match u32.
> + dev->prev_data->spl = val;
Why is ->spl (and the others too) unsigned long if it's only assigned u32?
> + }
> + break;
> +
> + case PMF_POLICY_SPPT:
> + if (dev->prev_data->sppt != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT : %d\n", val);
> + dev->prev_data->sppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_FPPT:
> + if (dev->prev_data->fppt != val) {
> + amd_pmf_send_cmd(dev, SET_FPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update FPPT : %d\n", val);
> + dev->prev_data->fppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_SPPT_APU_ONLY:
> + if (dev->prev_data->sppt_apuonly != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT_APU_ONLY, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT_APU_ONLY : %d\n", val);
> + dev->prev_data->sppt_apuonly = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_MIN:
> + if (dev->prev_data->stt_minlimit != val) {
> + amd_pmf_send_cmd(dev, SET_STT_MIN_LIMIT, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_MIN : %d\n", val);
> + dev->prev_data->stt_minlimit = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_APU:
> + if (dev->prev_data->stt_skintemp_apu != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_APU, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_APU : %d\n", val);
> + dev->prev_data->stt_skintemp_apu = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_HS2:
> + if (dev->prev_data->stt_skintemp_hs2 != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_HS2, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_HS2 : %d\n", val);
> + dev->prev_data->stt_skintemp_hs2 = val;
> + }
> + break;
> + }
> + }
> +}
> +
--
i.
WARNING: multiple messages have this Message-ID (diff)
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
markgross@kernel.org, basavaraj.natikar@amd.com,
jikos@kernel.org, benjamin.tissoires@redhat.com,
alexander.deucher@amd.com, christian.koenig@amd.com,
Xinhui.Pan@amd.com, airlied@gmail.com, daniel@ffwll.ch,
Patil.Reddy@amd.com, mario.limonciello@amd.com,
platform-driver-x86@vger.kernel.org, linux-input@vger.kernel.org,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary
Date: Wed, 27 Sep 2023 15:19:08 +0300 (EEST) [thread overview]
Message-ID: <18feb3c4-e8c4-9767-48a-7e3ef1c9cc@linux.intel.com> (raw)
In-Reply-To: <20230922175056.244940-5-Shyam-sundar.S-k@amd.com>
On Fri, 22 Sep 2023, Shyam Sundar S K wrote:
> PMF Policy binary is a encrypted and signed binary that will be part
> of the BIOS. PMF driver via the ACPI interface checks the existence
> of Smart PC bit. If the advertised bit is found, PMF driver walks
> the acpi namespace to find out the policy binary size and the address
> which has to be passed to the TA during the TA init sequence.
>
> The policy binary is comprised of inputs (or the events) and outputs
> (or the actions). With the PMF ecosystem, OEMs generate the policy
> binary (or could be multiple binaries) that contains a supported set
> of inputs and outputs which could be specifically carved out for each
> usage segment (or for each user also) that could influence the system
> behavior either by enriching the user experience or/and boost/throttle
> power limits.
>
> Once the TA init command succeeds, the PMF driver sends the changing
> events in the current environment to the TA for a constant sampling
> frequency time (the event here could be a lid close or open) and
> if the policy binary has corresponding action built within it, the
> TA sends the action for it in the subsequent enact command.
>
> If the inputs sent to the TA has no output defined in the policy
> binary generated by OEMs, there will be no action to be performed
> by the PMF driver.
>
> Example policies:
>
> 1) if slider is performance ; set the SPL to 40W
> Here PMF driver registers with the platform profile interface and
> when the slider position is changed, PMF driver lets the TA know
> about this. TA sends back an action to update the Sustained
> Power Limit (SPL). PMF driver updates this limit via the PMFW mailbox.
>
> 2) if user_away ; then lock the system
> Here PMF driver hooks to the AMD SFH driver to know the user presence
> and send the inputs to TA and if the condition is met, the TA sends
> the action of locking the system. PMF driver generates a uevent and
> based on the udev rule in the userland the system gets locked with
> systemctl.
>
> The intent here is to provide the OEM's to make a policy to lock the
> system when the user is away ; but the userland can make a choice to
> ignore it.
>
> and so on.
>
> The OEMs will have an utility to create numerous such policies and
> the policies shall be reviewed by AMD before signing and encrypting
> them. Policies are shared between operating systems to have seemless user
> experience.
>
> Since all this action has to happen via the "amdtee" driver, currently
> there is no caller for it in the kernel which can load the amdtee driver.
> Without amdtee driver loading onto the system the "tee" calls shall fail
> from the PMF driver. Hence an explicit "request_module" has been added
> to address this.
>
> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> ---
> +struct pmf_action_table {
> + unsigned long spl; /* in mW */
> + unsigned long sppt; /* in mW */
> + unsigned long sppt_apuonly; /* in mW */
> + unsigned long fppt; /* in mW */
> + unsigned long stt_minlimit; /* in mW */
> + unsigned long stt_skintemp_apu; /* in C */
> + unsigned long stt_skintemp_hs2; /* in C */
> +};
> +static void amd_pmf_apply_policies(struct amd_pmf_dev *dev, struct ta_pmf_enact_result *out)
> +{
> + u32 val;
> + int idx;
> +
> + for (idx = 0; idx < out->actions_count; idx++) {
> + val = out->actions_list[idx].value;
> + switch (out->actions_list[idx].action_index) {
> + case PMF_POLICY_SPL:
> + if (dev->prev_data->spl != val) {
> + amd_pmf_send_cmd(dev, SET_SPL, false, val, NULL);
> + dev_dbg(dev->dev, "update SPL : %d\n", val);
The %d does not match u32.
> + dev->prev_data->spl = val;
Why is ->spl (and the others too) unsigned long if it's only assigned u32?
> + }
> + break;
> +
> + case PMF_POLICY_SPPT:
> + if (dev->prev_data->sppt != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT : %d\n", val);
> + dev->prev_data->sppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_FPPT:
> + if (dev->prev_data->fppt != val) {
> + amd_pmf_send_cmd(dev, SET_FPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update FPPT : %d\n", val);
> + dev->prev_data->fppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_SPPT_APU_ONLY:
> + if (dev->prev_data->sppt_apuonly != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT_APU_ONLY, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT_APU_ONLY : %d\n", val);
> + dev->prev_data->sppt_apuonly = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_MIN:
> + if (dev->prev_data->stt_minlimit != val) {
> + amd_pmf_send_cmd(dev, SET_STT_MIN_LIMIT, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_MIN : %d\n", val);
> + dev->prev_data->stt_minlimit = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_APU:
> + if (dev->prev_data->stt_skintemp_apu != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_APU, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_APU : %d\n", val);
> + dev->prev_data->stt_skintemp_apu = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_HS2:
> + if (dev->prev_data->stt_skintemp_hs2 != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_HS2, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_HS2 : %d\n", val);
> + dev->prev_data->stt_skintemp_hs2 = val;
> + }
> + break;
> + }
> + }
> +}
> +
--
i.
WARNING: multiple messages have this Message-ID (diff)
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Cc: Xinhui.Pan@amd.com, Patil.Reddy@amd.com,
basavaraj.natikar@amd.com, dri-devel@lists.freedesktop.org,
jikos@kernel.org, amd-gfx@lists.freedesktop.org,
platform-driver-x86@vger.kernel.org, markgross@kernel.org,
Hans de Goede <hdegoede@redhat.com>,
benjamin.tissoires@redhat.com, mario.limonciello@amd.com,
linux-input@vger.kernel.org, alexander.deucher@amd.com,
christian.koenig@amd.com
Subject: Re: [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary
Date: Wed, 27 Sep 2023 15:19:08 +0300 (EEST) [thread overview]
Message-ID: <18feb3c4-e8c4-9767-48a-7e3ef1c9cc@linux.intel.com> (raw)
In-Reply-To: <20230922175056.244940-5-Shyam-sundar.S-k@amd.com>
On Fri, 22 Sep 2023, Shyam Sundar S K wrote:
> PMF Policy binary is a encrypted and signed binary that will be part
> of the BIOS. PMF driver via the ACPI interface checks the existence
> of Smart PC bit. If the advertised bit is found, PMF driver walks
> the acpi namespace to find out the policy binary size and the address
> which has to be passed to the TA during the TA init sequence.
>
> The policy binary is comprised of inputs (or the events) and outputs
> (or the actions). With the PMF ecosystem, OEMs generate the policy
> binary (or could be multiple binaries) that contains a supported set
> of inputs and outputs which could be specifically carved out for each
> usage segment (or for each user also) that could influence the system
> behavior either by enriching the user experience or/and boost/throttle
> power limits.
>
> Once the TA init command succeeds, the PMF driver sends the changing
> events in the current environment to the TA for a constant sampling
> frequency time (the event here could be a lid close or open) and
> if the policy binary has corresponding action built within it, the
> TA sends the action for it in the subsequent enact command.
>
> If the inputs sent to the TA has no output defined in the policy
> binary generated by OEMs, there will be no action to be performed
> by the PMF driver.
>
> Example policies:
>
> 1) if slider is performance ; set the SPL to 40W
> Here PMF driver registers with the platform profile interface and
> when the slider position is changed, PMF driver lets the TA know
> about this. TA sends back an action to update the Sustained
> Power Limit (SPL). PMF driver updates this limit via the PMFW mailbox.
>
> 2) if user_away ; then lock the system
> Here PMF driver hooks to the AMD SFH driver to know the user presence
> and send the inputs to TA and if the condition is met, the TA sends
> the action of locking the system. PMF driver generates a uevent and
> based on the udev rule in the userland the system gets locked with
> systemctl.
>
> The intent here is to provide the OEM's to make a policy to lock the
> system when the user is away ; but the userland can make a choice to
> ignore it.
>
> and so on.
>
> The OEMs will have an utility to create numerous such policies and
> the policies shall be reviewed by AMD before signing and encrypting
> them. Policies are shared between operating systems to have seemless user
> experience.
>
> Since all this action has to happen via the "amdtee" driver, currently
> there is no caller for it in the kernel which can load the amdtee driver.
> Without amdtee driver loading onto the system the "tee" calls shall fail
> from the PMF driver. Hence an explicit "request_module" has been added
> to address this.
>
> Signed-off-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
> ---
> +struct pmf_action_table {
> + unsigned long spl; /* in mW */
> + unsigned long sppt; /* in mW */
> + unsigned long sppt_apuonly; /* in mW */
> + unsigned long fppt; /* in mW */
> + unsigned long stt_minlimit; /* in mW */
> + unsigned long stt_skintemp_apu; /* in C */
> + unsigned long stt_skintemp_hs2; /* in C */
> +};
> +static void amd_pmf_apply_policies(struct amd_pmf_dev *dev, struct ta_pmf_enact_result *out)
> +{
> + u32 val;
> + int idx;
> +
> + for (idx = 0; idx < out->actions_count; idx++) {
> + val = out->actions_list[idx].value;
> + switch (out->actions_list[idx].action_index) {
> + case PMF_POLICY_SPL:
> + if (dev->prev_data->spl != val) {
> + amd_pmf_send_cmd(dev, SET_SPL, false, val, NULL);
> + dev_dbg(dev->dev, "update SPL : %d\n", val);
The %d does not match u32.
> + dev->prev_data->spl = val;
Why is ->spl (and the others too) unsigned long if it's only assigned u32?
> + }
> + break;
> +
> + case PMF_POLICY_SPPT:
> + if (dev->prev_data->sppt != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT : %d\n", val);
> + dev->prev_data->sppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_FPPT:
> + if (dev->prev_data->fppt != val) {
> + amd_pmf_send_cmd(dev, SET_FPPT, false, val, NULL);
> + dev_dbg(dev->dev, "update FPPT : %d\n", val);
> + dev->prev_data->fppt = val;
> + }
> + break;
> +
> + case PMF_POLICY_SPPT_APU_ONLY:
> + if (dev->prev_data->sppt_apuonly != val) {
> + amd_pmf_send_cmd(dev, SET_SPPT_APU_ONLY, false, val, NULL);
> + dev_dbg(dev->dev, "update SPPT_APU_ONLY : %d\n", val);
> + dev->prev_data->sppt_apuonly = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_MIN:
> + if (dev->prev_data->stt_minlimit != val) {
> + amd_pmf_send_cmd(dev, SET_STT_MIN_LIMIT, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_MIN : %d\n", val);
> + dev->prev_data->stt_minlimit = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_APU:
> + if (dev->prev_data->stt_skintemp_apu != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_APU, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_APU : %d\n", val);
> + dev->prev_data->stt_skintemp_apu = val;
> + }
> + break;
> +
> + case PMF_POLICY_STT_SKINTEMP_HS2:
> + if (dev->prev_data->stt_skintemp_hs2 != val) {
> + amd_pmf_send_cmd(dev, SET_STT_LIMIT_HS2, false, val, NULL);
> + dev_dbg(dev->dev, "update STT_SKINTEMP_HS2 : %d\n", val);
> + dev->prev_data->stt_skintemp_hs2 = val;
> + }
> + break;
> + }
> + }
> +}
> +
--
i.
next prev parent reply other threads:[~2023-09-27 12:47 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-22 17:50 [PATCH 00/15] Introduce PMF Smart PC Solution Builder Feature Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-22 17:50 ` [PATCH 01/15] platform/x86/amd/pmf: Add PMF TEE interface Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-26 16:42 ` Ilpo Järvinen
2023-09-26 16:42 ` Ilpo Järvinen
2023-09-26 16:42 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 02/15] platform/x86/amd/pmf: Add support PMF-TA interaction Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-26 16:48 ` Ilpo Järvinen
2023-09-26 16:48 ` Ilpo Järvinen
2023-09-26 16:48 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 03/15] platform/x86/amd/pmf: Change signature of amd_pmf_set_dram_addr Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-26 16:52 ` Ilpo Järvinen
2023-09-26 16:52 ` Ilpo Järvinen
2023-09-26 16:52 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 04/15] platform/x86/amd/pmf: Add support for PMF Policy Binary Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-22 18:51 ` Mario Limonciello
2023-09-22 18:51 ` Mario Limonciello
2023-09-30 3:55 ` Shyam Sundar S K
2023-09-30 3:55 ` Shyam Sundar S K
2023-09-26 17:05 ` Ilpo Järvinen
2023-09-26 17:05 ` Ilpo Järvinen
2023-09-26 17:05 ` Ilpo Järvinen
2023-09-27 12:19 ` Ilpo Järvinen [this message]
2023-09-27 12:19 ` Ilpo Järvinen
2023-09-27 12:19 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 05/15] platform/x86/amd/pmf: change debugfs init sequence Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-26 16:53 ` Ilpo Järvinen
2023-09-26 16:53 ` Ilpo Järvinen
2023-09-26 16:53 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 06/15] platform/x86/amd/pmf: Add support to get inputs from other subsystems Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-26 17:08 ` Ilpo Järvinen
2023-09-26 17:08 ` Ilpo Järvinen
2023-09-26 17:08 ` Ilpo Järvinen
2023-09-30 8:40 ` Shyam Sundar S K
2023-09-30 8:40 ` Shyam Sundar S K
2023-09-30 8:40 ` Shyam Sundar S K
2023-10-02 9:10 ` Ilpo Järvinen
2023-10-02 9:10 ` Ilpo Järvinen
2023-10-02 9:10 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 07/15] platform/x86/amd/pmf: Add support update p3t limit Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-27 12:19 ` Ilpo Järvinen
2023-09-27 12:19 ` Ilpo Järvinen
2023-09-27 12:19 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 08/15] platform/x86/amd/pmf: Add support to update system state Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-25 21:42 ` kernel test robot
2023-09-25 21:42 ` kernel test robot
2023-09-27 12:22 ` Ilpo Järvinen
2023-09-27 12:22 ` Ilpo Järvinen
2023-09-27 12:22 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 09/15] platform/x86/amd/pmf: Add facility to dump TA inputs Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-27 12:25 ` Ilpo Järvinen
2023-09-27 12:25 ` Ilpo Järvinen
2023-09-27 12:25 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 10/15] platform/x86/amd/pmf: Add capability to sideload of policy binary Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-25 2:14 ` kernel test robot
2023-09-25 2:14 ` kernel test robot
2023-09-27 12:33 ` Ilpo Järvinen
2023-09-27 12:33 ` Ilpo Järvinen
2023-09-27 12:33 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 11/15] platform/x86/amd/pmf: dump policy binary data Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-22 19:01 ` Mario Limonciello
2023-09-22 19:01 ` Mario Limonciello
2023-09-30 4:41 ` Shyam Sundar S K
2023-09-30 4:41 ` Shyam Sundar S K
2023-09-22 17:50 ` [PATCH 12/15] platform/x86/amd/pmf: Add PMF-AMDGPU get interface Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-27 12:54 ` Ilpo Järvinen
2023-09-27 12:54 ` Ilpo Järvinen
2023-09-27 12:54 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 13/15] platform/x86/amd/pmf: Add PMF-AMDGPU set interface Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-25 16:27 ` Deucher, Alexander
2023-09-25 16:27 ` Deucher, Alexander
2023-09-25 16:27 ` Deucher, Alexander
2023-09-25 16:30 ` Mario Limonciello
2023-09-25 16:30 ` Mario Limonciello
2023-09-26 11:17 ` Shyam Sundar S K
2023-09-26 11:17 ` Shyam Sundar S K
2023-09-26 11:15 ` Shyam Sundar S K
2023-09-26 11:15 ` Shyam Sundar S K
2023-09-26 10:35 ` Hans de Goede
2023-09-26 10:35 ` Hans de Goede
2023-09-26 11:24 ` Shyam Sundar S K
2023-09-26 11:24 ` Shyam Sundar S K
2023-09-26 12:56 ` Hans de Goede
2023-09-26 12:56 ` Hans de Goede
2023-09-26 13:17 ` Christian König
2023-09-26 13:17 ` Christian König
2023-09-26 13:48 ` Shyam Sundar S K
2023-09-26 13:48 ` Shyam Sundar S K
2023-09-27 13:04 ` Hans de Goede
2023-09-27 13:04 ` Hans de Goede
2023-09-27 13:47 ` Shyam Sundar S K
2023-09-27 13:47 ` Shyam Sundar S K
2023-09-27 13:36 ` Ilpo Järvinen
2023-09-27 13:36 ` Ilpo Järvinen
2023-09-27 13:36 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 14/15] platform/x86/amd/pmf: Add PMF-AMDSFH interface for HPD Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-22 19:04 ` Mario Limonciello
2023-09-22 19:04 ` Mario Limonciello
2023-09-22 21:04 ` Mario Limonciello
2023-09-22 21:04 ` Mario Limonciello
2023-09-27 13:32 ` Ilpo Järvinen
2023-09-27 13:32 ` Ilpo Järvinen
2023-09-27 13:32 ` Ilpo Järvinen
2023-09-22 17:50 ` [PATCH 15/15] platform/x86/amd/pmf: Add PMF-AMDSFH interface for ALS Shyam Sundar S K
2023-09-22 17:50 ` Shyam Sundar S K
2023-09-22 19:06 ` Mario Limonciello
2023-09-22 19:06 ` Mario Limonciello
2023-09-27 13:33 ` Ilpo Järvinen
2023-09-27 13:33 ` Ilpo Järvinen
2023-09-27 13:33 ` Ilpo Järvinen
2023-09-27 13:48 ` Shyam Sundar S K
2023-09-27 13:48 ` Shyam Sundar S K
2023-09-27 13:48 ` Shyam Sundar S K
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18feb3c4-e8c4-9767-48a-7e3ef1c9cc@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=Patil.Reddy@amd.com \
--cc=Shyam-sundar.S-k@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=basavaraj.natikar@amd.com \
--cc=benjamin.tissoires@redhat.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=markgross@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.