<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 08-04-2025 18:31, Rafael J. Wysocki
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAJZ5v0hp-bYn8JFiBnTgrSdJWHm1jgCjcvbVZkzeOaySjvAQQg@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">On Fri, Apr 4, 2025 at 2:53 PM Gupta, Anshuman <a class="moz-txt-link-rfc2396E" href="mailto:anshuman.gupta@intel.com"><anshuman.gupta@intel.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
/snip
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
Exactly like I said: If you only allow one driver to use the _DSM to
request the Aux power from a given Root Port, it will have all of
the information and does not need to be notified about any changes.
Since no one else is allowed to use this interface for that Root
Port, no one else will need a notifier either. For this to work,
you need some mechanism allowing drivers to claim the interface so
no one else can use it (on a per Root Port basis) which is currently missing
</pre>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">AFAICS.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
IMHO such kind of mechanism will require to add Root Port specific
data structure to claim the interface. But real problem is the criteria to claim
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">the interface.
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">Is first PCIe Non-Bridge Endpoint Function 0 driver can be criteria
to claim the Interface. Or first come and first serve approach ?
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
IMV, the first PCIe Non-Bridge Endpoint Function 0 driver approach would be
sort of fragile and cumbersome to enforce.
First come, first serve is much simpler and should be sufficient for now AFAICS.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
We are enabling VRSR only for default vga boot device.
As it needed only GPU driving the display for better user experience.
Can we use same logic vga_default_device() to claim the interface under root port.
That will simplify the criteria to claim the interface.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">
Basically, you need to prevent somebody else from running
DSM_PCI_D3COLD_AUX_POWER_LIMIT concurrently for the given Root Port
and store the information that it has been run already.
Personally, I'd add aux_power_limit to struct acpi_device_power and
I'd use a static mutex in pci_acpi_request_d3cold_aux_power() along
the lines of:
1. Acquire the mutex.
2. If power.aux_power_limit is set for the ACPI companion of pci_dev,
release the mutex and bail out.
3. Evaluate DSM_PCI_D3COLD_AUX_POWER_LIMIT and if it fails, release
the mutex and bail out.
4. Set power.aux_power_limit for the ACPI companion of pci_dev to the
requested value.
5. Release the mutex.
Of course, this would only allow it to be set once per kernel boot, so
in order to handle hibernation properly, the same Aux power limit
would need to be requested again automatically on Root Port restore.</pre>
</blockquote>
<p> I've incorporated the above suggestion in v4 patch <a href="https://patchwork.freedesktop.org/patch/656187/?series=145342&rev=4">[v4,02/11]
PCI/ACPI: Per root port allow one Aux power limit request -
Patchwork</a> , except for the Aux power re-request after
hibernation exit, as we didn't observe any issues with VRSR post
hibernation.</p>
<p>Regards,<br>
Badal</p>
<blockquote type="cite" cite="mid:CAJZ5v0hp-bYn8JFiBnTgrSdJWHm1jgCjcvbVZkzeOaySjvAQQg@mail.gmail.com">
<pre wrap="" class="moz-quote-pre">
</pre>
</blockquote>
</body>
</html>