RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn Thanks a lot for your reply and explanations. Sorry for my late reply due to some other emergencies. > >On Tue, May 02, 2017 at 12:02:53PM +, Patel, Mayurkumar wrote: >> >On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar >> ><mayurkumar.pa...@intel.com

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn Thanks a lot for your reply and explanations. Sorry for my late reply due to some other emergencies. > >On Tue, May 02, 2017 at 12:02:53PM +, Patel, Mayurkumar wrote: >> >On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar >> > wrote: >> >>>On

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn > >On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar ><mayurkumar.pa...@intel.com> wrote: >> Hi Bjorn/Kaya, >> >> >>> >>>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >>>>> Like you said, what do we do by default is th

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn > >On Fri, Apr 21, 2017 at 2:46 AM, Patel, Mayurkumar > wrote: >> Hi Bjorn/Kaya, >> >> >>> >>>On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >>>>> Like you said, what do we do by default is the question. Should we opt >>>&

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

> >On 4/21/2017 3:46 AM, Patel, Mayurkumar wrote: >> If we want to follow above approach then shall we consider having something >> similar as following? > >Do you see this problem if you boot with pcie_aspm.policy=powersave option? > No problems. with pcie

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

> >On 4/21/2017 3:46 AM, Patel, Mayurkumar wrote: >> If we want to follow above approach then shall we consider having something >> similar as following? > >Do you see this problem if you boot with pcie_aspm.policy=powersave option? > No problems. with pcie

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn/Kaya, > >On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >>> Like you said, what do we do by default is the question. Should we opt >>> for safe like we are doing, or try to save some power. >> I think safety is paramount. Every user should be able to boot safely >> without any kernel

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

Hi Bjorn/Kaya, > >On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >>> Like you said, what do we do by default is the question. Should we opt >>> for safe like we are doing, or try to save some power. >> I think safety is paramount. Every user should be able to boot safely >> without any kernel

RE: [PATCH V3] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >Hi Bjorn, > >On 3/9/2017 5:27 PM, Bjorn Helgaas wrote: >> How hard do you think it would be to rework this path slightly so we: >> >> - call pcie_aspm_init_link_state() for every device, maybe from >> pci_init_capabilities() >> >> - for bridges, have pcie_aspm_init_link_state()

RE: [PATCH V3] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >Hi Bjorn, > >On 3/9/2017 5:27 PM, Bjorn Helgaas wrote: >> How hard do you think it would be to rework this path slightly so we: >> >> - call pcie_aspm_init_link_state() for every device, maybe from >> pci_init_capabilities() >> >> - for bridges, have pcie_aspm_init_link_state()

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

Hi Kaya > >Hi Mayurkumar > >On 3/2/2017 11:05 AM, Patel, Mayurkumar wrote: >>> >>> Hi Bjorn, >>> >>> On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote: >>>>> I was trying to figure out when to use saved values vs. the values in >

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

Hi Kaya > >Hi Mayurkumar > >On 3/2/2017 11:05 AM, Patel, Mayurkumar wrote: >>> >>> Hi Bjorn, >>> >>> On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote: >>>>> I was trying to figure out when to use saved values vs. the values in >

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >Hi Bjorn, > >On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote: >>> I was trying to figure out when to use saved values vs. the values in >>> registers by looking at the enable_cnt. >>> enable_cnt is 0 during boot on my system. >> enable_cnt for the root

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >Hi Bjorn, > >On 2/28/2017 1:57 PM, Patel, Mayurkumar wrote: >>> I was trying to figure out when to use saved values vs. the values in >>> registers by looking at the enable_cnt. >>> enable_cnt is 0 during boot on my system. >> enable_cnt for the root

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >On 2/28/2017 6:03 AM, Patel, Mayurkumar wrote: >>> - /* Save default state */ >>> - link->aspm_default = link->aspm_enabled; >> But, I am finding a problem with this change, if Policy is set to default, >> BIOS enables ASPM L1, but pcie_config_a

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >On 2/28/2017 6:03 AM, Patel, Mayurkumar wrote: >>> - /* Save default state */ >>> - link->aspm_default = link->aspm_enabled; >> But, I am finding a problem with this change, if Policy is set to default, >> BIOS enables ASPM L1, but pcie_config_a

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >When the operating system is booted with the default ASPM policy >(POLICY_DEFAULT), the current code is determining the ASPM policy >set up by the BIOS by querying the enable/disable states from ASPM >registers. > >In the case of hotplug removal, the ASPM registers get cleared by >calling the

RE: [PATCH V2] PCI/ASPM: reconfigure ASPM following hotplug for POLICY_DEFAULT

> >When the operating system is booted with the default ASPM policy >(POLICY_DEFAULT), the current code is determining the ASPM policy >set up by the BIOS by querying the enable/disable states from ASPM >registers. > >In the case of hotplug removal, the ASPM registers get cleared by >calling the

RE: [PATCH v2 1/8] PCI: pciehp: Rename pcie_isr() locals for clarity

> > On Tue, Sep 13, 2016 at 10:05:31AM +, Patel, Mayurkumar wrote: > > > > > Rename "detected" and "intr_loc" to "status" and "events" for clarity. > > > "status" is the value we read from the Slot

RE: [PATCH v2 1/8] PCI: pciehp: Rename pcie_isr() locals for clarity

> > On Tue, Sep 13, 2016 at 10:05:31AM +, Patel, Mayurkumar wrote: > > > > > Rename "detected" and "intr_loc" to "status" and "events" for clarity. > > > "status" is the value we read from the Slot

RE: [PATCH v2 1/8] PCI: pciehp: Rename pcie_isr() locals for clarity

> Rename "detected" and "intr_loc" to "status" and "events" for clarity. > "status" is the value we read from the Slot Status register; "events" is > the set of hot-plug events we need to process. No functional change > intended. > > Signed-off-by: Bjorn Helgaas > --- >

RE: [PATCH v2 1/8] PCI: pciehp: Rename pcie_isr() locals for clarity

> Rename "detected" and "intr_loc" to "status" and "events" for clarity. > "status" is the value we read from the Slot Status register; "events" is > the set of hot-plug events we need to process. No functional change > intended. > > Signed-off-by: Bjorn Helgaas > --- >