On Friday 27 July 2018 15:26:19 Bjorn Helgaas wrote:
> [+cc Rafael, Richard, Carlos, Pali, Takashi, Andy, Colin for question
> about how to expose ASPM power management in sysfs]
>
> On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote:
> > ...
> > And some suggestions from Bjorn here:
> > h
On Mon, Jul 30, 2018 at 10:32:10AM +0200, Lukas Wunner wrote:
> On Fri, Jul 27, 2018 at 03:26:19PM -0500, Bjorn Helgaas wrote:
> > The question is where those sysfs files should be. Currently they are
> > associated with the device at the *upstream* end of the link. In the
> > example above, they
On Fri, Jul 27, 2018 at 1:26 PM, Bjorn Helgaas wrote:
> [+cc Rafael, Richard, Carlos, Pali, Takashi, Andy, Colin for question
> about how to expose ASPM power management in sysfs]
>
> On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote:
>> ...
>> And some suggestions from Bjorn here:
>> htt
On 7/30/2018 7:14 AM, Bjorn Helgaas wrote:
However, the end of sec 5.4.1 does make it clear that the functions
need not have the same ASPM configuration, and it gives rules for how
those different settings should affect the shared link. Since it
mentions different ASPM Control fields for the dif
On Sat, Jul 28, 2018 at 05:16:13PM -0700, Sinan Kaya wrote:
> On 7/27/2018 1:26 PM, Bjorn Helgaas wrote:
> > - A link can lead to a multi-function device, and the spec allows
> > those functions to have different ASPM settings (see PCIe r4.0,
> > sec 5.4.1). With the sysfs files at the u
On Fri, Jul 27, 2018 at 03:26:19PM -0500, Bjorn Helgaas wrote:
> The question is where those sysfs files should be. Currently they are
> associated with the device at the *upstream* end of the link. In the
> example above, they're associated with the Root Port:
>
> /sys/devices/pci:00/
On 7/27/2018 1:26 PM, Bjorn Helgaas wrote:
- A link can lead to a multi-function device, and the spec allows
those functions to have different ASPM settings (see PCIe r4.0,
sec 5.4.1). With the sysfs files at the upstream end of the link,
we have no way to configure those function
On Fri, 27 Jul 2018 22:26:19 +0200,
Bjorn Helgaas wrote:
>
> [+cc Rafael, Richard, Carlos, Pali, Takashi, Andy, Colin for question
> about how to expose ASPM power management in sysfs]
>
> On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote:
> > ...
> > And some suggestions from Bjorn here
[+cc Rafael, Richard, Carlos, Pali, Takashi, Andy, Colin for question
about how to expose ASPM power management in sysfs]
On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote:
> ...
> And some suggestions from Bjorn here:
> https://www.spinics.net/lists/linux-pci/msg60541.html
>
> This patc
On Thu, May 10, 2018 at 04:39:12PM -0700, Rajat Jain wrote:
> Currently, the linux kernel disables ASPM when a device is
> removed from the kernel. But it is not enabled again when
> a new device is added on that slot even if it was originally
> enabled (by the BIOS) when the system booted up (assu
> On Thu, May 10, 2018 at 4:39 PM Rajat Jain wrote:
>>
>> Currently, the linux kernel disables ASPM when a device is
>> removed from the kernel. But it is not enabled again when
>> a new device is added on that slot even if it was originally
>> enabled (by the BIOS) when the system booted up (assu
Hello Bjorn,
Just checking to see if this one fell through the cracks? It isn't
solving any issues, but providing a tool for ASPM tweaking in user
space, which may be useful.
Thanks,
Rajat
On Thu, May 10, 2018 at 4:39 PM Rajat Jain wrote:
>
> Currently, the linux kernel disables ASPM when a dev
Currently, the linux kernel disables ASPM when a device is
removed from the kernel. But it is not enabled again when
a new device is added on that slot even if it was originally
enabled (by the BIOS) when the system booted up (assuming
POLICY_DEFAULT).
This was earlier discussed here:
https://www.
13 matches
Mail list logo
