Matthew Wilcox wrote:
I don't know the ASPM code at all, and it's probably quicker if someone
who does takes a look at this. The ARI ECN affects the ASPM specification
to this extent (translated into diff -u format by moi):
5.4.1. Active State Power Management (ASPM)
<following Implementation Note on Isochronous Traffic and ASPM>
+For ARI Devices, ASPM Control is determined solely by the setting in
+Function 0, regardless of Function 0's D-state. The ASPM Control settings
+in other Functions are ignored by the component.
-An Upstream Port with a multi-Function device may be programmed
-with different values in its respective Active_PM_En registers of each
+An Upstream Port with a non-ARI multi-Function device may be programmed
+with different values in its respective ASPM Control registers of each
Function. The policy for such a component will be
dictated by the most active common denominator among all D0 Functions
according to the following rules:
To recap ARI: It changes the interpretation of config cycles in the
upstream bridge and the downstream device from 5 bits of device and 3
bits of function to 0 bits of device and 8 bits of function. But (in
some ways) it makes those functions less independent of each other.
This is one of those ways; all the functions are now performing ASPM in
unison instead of individually.
I have no idea how this affects the ASPM code, but someone who does
understand ASPM should look into this before we see a lot of ARI devices
on the market and people complaining that ASPM doesn't work with them.
Because Linux ASPM driver sets ASPM Control bits the same in all
functions, I think Linux has no compatibility issues about this.
Thanks,
Kenji Kaneshige
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
