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 4/17/2017 12:38 PM, Bjorn Helgaas wrote:
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 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
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
> for safe like we are doing, or try to save some power.
I think
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
for safe like we are doing, or try to save some power.
>>> I think safety is paramount.
>
>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_aspm.policy=powersave(L1SS are not enab
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?
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate
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 param
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 parameters. We don't want us
On Fri, Apr 14, 2017 at 5:17 PM, Sinan Kaya wrote:
> On 4/14/2017 5:44 PM, Bjorn Helgaas wrote:
>> I think there's an argument to be made that if we care about ASPM
>> configuration, we should be using a non-POLICY_DEFAULT setting. And I
>> think there's value in having POLICY_DEFAULT be the abso
On 4/14/2017 5:44 PM, Bjorn Helgaas wrote:
> I think there's an argument to be made that if we care about ASPM
> configuration, we should be using a non-POLICY_DEFAULT setting. And I
> think there's value in having POLICY_DEFAULT be the absolute lowest-
> risk setting, which I think means option 1
[+cc Myron, lkml]
On Fri, Apr 14, 2017 at 03:12:35PM -0400, Sinan Kaya wrote:
> Bjorn,
>
> On 4/12/2017 3:19 PM, Rajat Jain wrote:
> > On Fri, Apr 7, 2017 at 9:55 PM, Sinan Kaya wrote:
> >> Now that we added a hook to be called from device_add, save the
> >> default values from the HW registers
Bjorn,
On 4/12/2017 3:19 PM, Rajat Jain wrote:
> On Fri, Apr 7, 2017 at 9:55 PM, Sinan Kaya wrote:
>> Now that we added a hook to be called from device_add, save the
>> default values from the HW registers early in the boot for further
>> reuse during hot device add/remove operations.
>>
>> If th
On Fri, Apr 7, 2017 at 9:55 PM, Sinan Kaya wrote:
> Now that we added a hook to be called from device_add, save the
> default values from the HW registers early in the boot for further
> reuse during hot device add/remove operations.
>
> If the link is down during boot, assume that we want to enab
13 matches
Mail list logo