From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
<intel-xe@lists.freedesktop.org>, <linux-acpi@vger.kernel.org>,
<linux-pci@vger.kernel.org>
Cc: <anshuman.gupta@intel.com>, <rafael@kernel.org>,
<lenb@kernel.org>, <bhelgaas@google.com>,
<ilpo.jarvinen@linux.intel.com>, <lucas.demarchi@intel.com>,
<rodrigo.vivi@intel.com>, <varun.gupta@intel.com>,
<ville.syrjala@linux.intel.com>, <uma.shankar@intel.com>
Subject: Re: [PATCH v3 01/11] PCI/ACPI: Add D3cold Aux Power Limit_DSM method
Date: Thu, 29 May 2025 12:41:07 +0530 [thread overview]
Message-ID: <d73fdbbf-699d-48cf-948f-f8cf678ce165@intel.com> (raw)
In-Reply-To: <b5a54c14-a6b2-4a91-9618-c03cc4e775ed@intel.com>
On 29-05-2025 11:48, Nilawar, Badal wrote:
>
> On 24-05-2025 11:30, Sathyanarayanan Kuppuswamy wrote:
>>
>> On 5/23/25 12:01 PM, Badal Nilawar wrote:
>>> From: Anshuman Gupta<anshuman.gupta@intel.com>
>>>
>>> Implement _DSM method 0Ah according to PCI firmware specifications,
>>> section 4.6.10 Rev 3.3., to request auxilary power needed for the
>>> device when in D3Cold.
>>>
>>> Note that this implementation assumes only a single device below the
>>> Downstream Port will request for Aux Power Limit under a given
>>> Root Port because it does not track and aggregate requests
>>> from all child devices below the Downstream Port as required
>>> by Section 4.6.10 Rev 3.3.
>>
>> Add some info about why you are not adding this support?
> Scope is limited to enable the use case of VRAM-SR on BMG GPU. I will
> mention this in cover letter.
>>
>>> One possible mitigation would be only allowing only first PCIe
>>> Non-Bridge Endpoint Function 0 driver to call_DSM method 0Ah.
>>>
>>> V2(Bjorn/Rafael):
>>> - Call acpi_dsm_check() to find method 0Ah supported
>>> - Return retry interval to caller
>>>
>>> Signed-off-by: Varun Gupta<varun.gupta@intel.com>
>>> Signed-off-by: Badal Nilawar<badal.nilawar@intel.com>
>>> Signed-off-by: Anshuman Gupta<anshuman.gupta@intel.com>
>>> ---
>>> drivers/pci/pci-acpi.c | 87
>>> ++++++++++++++++++++++++++++++++++++++++
>>> include/linux/pci-acpi.h | 8 ++++
>>> 2 files changed, 95 insertions(+)
>>>
>>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>>> index af370628e583..76b19525535f 100644
>>> --- a/drivers/pci/pci-acpi.c
>>> +++ b/drivers/pci/pci-acpi.c
>>> @@ -1421,6 +1421,93 @@ static void pci_acpi_optimize_delay(struct
>>> pci_dev *pdev,
>>> ACPI_FREE(obj);
>>> }
>>> +/**
>>> + * pci_acpi_request_d3cold_aux_power - Request aux power while
>>> device is in D3Cold
>>> + * @dev: PCI device instance
>>> + * @requested_power: Requested auxiliary power in milliwatts
>>> + * @retry_interval: Retry interval returned by platform to retry
>>> auxiliary
>>> + * power request
>>> + *
>>> + * This function sends a request to the host BIOS via root port
>>> ACPI _DSM Function 0Ah
>>> + * for the auxiliary power needed by the PCI device when it is in
>>> D3Cold.
>>> + * It checks and evaluates the _DSM (Device Specific Method) to
>>> request the auxiliary
>>> + * power and handles the response accordingly.
>>> + *
>>> + * This function shall be only called by 1st non-bridge Endpoint
>>> driver
>>> + * on Function 0. For a Multi-Function Device, the driver for
>>> Function 0 is
>>> + * required to report an aggregate power requirement covering all
>>> + * functions contained within the device.
>>> + *
>>> + * Return: Returns 0 on success and errno on failure.
>>> + */
>>> +int pci_acpi_request_d3cold_aux_power(struct pci_dev *dev, u32
>>> requested_power,
>>> + u32 *retry_interval)
>>> +{
>>> + union acpi_object in_obj = {
>>> + .integer.type = ACPI_TYPE_INTEGER,
>>> + .integer.value = requested_power,
>>> + };
>>> +
>>> + union acpi_object *out_obj;
>>> + acpi_handle handle;
>>> + int result, ret = -EINVAL;
>>> +
>>> + if (!dev)
>>> + return -EINVAL;
>>
>> Is retry_interval param optional? If not may be a check here for non
>> NULL condition is needed.
> Yes its optional, its up to caller weather to retry or not.
I will make this param mandatory and add NULL check here. Then its up to
caller to decide whether to retry.
Thanks,
Badal
>>
>>> +
>>> + handle = ACPI_HANDLE(&dev->dev);
>>> + if (!handle)
>>> + return -EINVAL;
>>> +
>>> + if (!acpi_check_dsm(handle, &pci_acpi_dsm_guid, 4, 1 <<
>>> DSM_PCI_D3COLD_AUX_POWER_LIMIT)) {
>>> + pci_dbg(dev, "ACPI _DSM 0%Xh not supported\n",
>>> DSM_PCI_D3COLD_AUX_POWER_LIMIT);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + out_obj = acpi_evaluate_dsm_typed(handle, &pci_acpi_dsm_guid, 4,
>>> + DSM_PCI_D3COLD_AUX_POWER_LIMIT,
>>> + &in_obj, ACPI_TYPE_INTEGER);
>>> + if (!out_obj)
>>> + return -EINVAL;
>>> +
>>> + result = out_obj->integer.value;
>>> + if (retry_interval)
>>> + *retry_interval = 0;
>>> +
>>> + switch (result) {
>>> + case 0x0:
>>> + pci_dbg(dev, "D3cold Aux Power %u mW request denied\n",
>>> + requested_power);
>>
>> is this not a error?
>
> No its not error. BIOS Firmware can deny the aux power request.
>
> Regards,
> Badal
>
>>
>>> + break;
>>> + case 0x1:
>>> + pci_info(dev, "D3cold Aux Power request granted: %u mW\n",
>>> + requested_power);
>>> + ret = 0;
>>> + break;
>>> + case 0x2:
>>> + pci_info(dev, "D3cold Aux Power: Main power won't be
>>> removed\n");
>>> + ret = -EBUSY;
>>> + break;
>>> + default:
>>> + if (result >= 0x11 && result <= 0x1F) {
>>> + if (retry_interval) {
>>> + *retry_interval = result & 0xF;
>>> + pci_warn(dev, "D3cold Aux Power request needs retry
>>> interval: %u seconds\n",
>>> + *retry_interval);
>>> + ret = -EAGAIN;
>>> + }
>>> + } else {
>>> + pci_err(dev, "D3cold Aux Power: Reserved or unsupported
>>> response: 0x%x\n",
>>> + result);
>>> + }
>>> + break;
>>> + }
>>> +
>>> + ACPI_FREE(out_obj);
>>> + return ret;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pci_acpi_request_d3cold_aux_power);
>>> +
>>> static void pci_acpi_set_external_facing(struct pci_dev *dev)
>>> {
>>> u8 val;
>>> diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
>>> index 078225b514d4..1705d03bfe26 100644
>>> --- a/include/linux/pci-acpi.h
>>> +++ b/include/linux/pci-acpi.h
>>> @@ -121,6 +121,7 @@ extern const guid_t pci_acpi_dsm_guid;
>>> #define DSM_PCI_DEVICE_NAME 0x07
>>> #define DSM_PCI_POWER_ON_RESET_DELAY 0x08
>>> #define DSM_PCI_DEVICE_READINESS_DURATIONS 0x09
>>> +#define DSM_PCI_D3COLD_AUX_POWER_LIMIT 0x0A
>>> #ifdef CONFIG_PCIE_EDR
>>> void pci_acpi_add_edr_notifier(struct pci_dev *pdev);
>>> @@ -132,10 +133,17 @@ static inline void
>>> pci_acpi_remove_edr_notifier(struct pci_dev *pdev) { }
>>> int pci_acpi_set_companion_lookup_hook(struct acpi_device
>>> *(*func)(struct pci_dev *));
>>> void pci_acpi_clear_companion_lookup_hook(void);
>>> +int pci_acpi_request_d3cold_aux_power(struct pci_dev *dev, u32
>>> requested_power,
>>> + u32 *retry_interval);
>>> #else /* CONFIG_ACPI */
>>> static inline void acpi_pci_add_bus(struct pci_bus *bus) { }
>>> static inline void acpi_pci_remove_bus(struct pci_bus *bus) { }
>>> +static int pci_acpi_request_d3cold_aux_power(struct pci_dev *dev,
>>> u32 requested_power,
>>> + u32 *retry_interval)
>>> +{
>>> + return -EOPNOTSUPP;
>>> +}
>>> #endif /* CONFIG_ACPI */
>>> #endif /* _PCI_ACPI_H_ */
>>
next prev parent reply other threads:[~2025-05-29 7:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 19:01 [PATCH v3 00/11] VRAM Self Refresh Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 01/11] PCI/ACPI: Add D3cold Aux Power Limit_DSM method Badal Nilawar
2025-05-24 6:00 ` Sathyanarayanan Kuppuswamy
2025-05-29 6:18 ` Nilawar, Badal
2025-05-29 7:11 ` Nilawar, Badal [this message]
2025-05-23 19:01 ` [PATCH v3 02/11] PCI/ACPI: Per root port allow one Aux power limit request Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 03/11] PCI/ACPI: Add PERST# Assertion Delay _DSM method Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 04/11] drm/xe/vrsr: Introduce flag has_vrsr Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 05/11] drm/xe/vrsr: Detect VRSR Capability Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 06/11] drm/xe/vrsr: Initialize VRSR feature Badal Nilawar
2025-05-23 21:33 ` kernel test robot
2025-05-23 19:01 ` [PATCH v3 07/11] drm/xe/vrsr: Enable VRSR on default VGA boot device Badal Nilawar
2025-05-23 22:04 ` kernel test robot
2025-05-23 19:01 ` [PATCH v3 08/11] drm/xe/vrsr: Refactor d3cold.allowed to a enum Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 09/11] drm/xe/pm: D3Cold target state Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 10/11] drm/xe/vrsr: Enable VRSR Badal Nilawar
2025-05-23 19:01 ` [PATCH v3 11/11] drm/xe/vrsr: Introduce a debugfs node named vrsr_capable Badal Nilawar
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=d73fdbbf-699d-48cf-948f-f8cf678ce165@intel.com \
--to=badal.nilawar@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=bhelgaas@google.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=rafael@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=uma.shankar@intel.com \
--cc=varun.gupta@intel.com \
--cc=ville.syrjala@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox