lkml.org 
[lkml]   [2022]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300 Series Chipset SATA Controller
From
Dear Damien,


Am 23.03.22 um 09:36 schrieb Paul Menzel:

> Am 23.03.22 um 09:24 schrieb Damien Le Moal:
>> On 3/23/22 15:55, Paul Menzel wrote:
>
>>> Am 23.03.22 um 06:01 schrieb Damien Le Moal:
>>>> On 3/22/22 06:51, Limonciello, Mario wrote:
>
>>>>>> -----Original Message-----
>>>>>> From: Paul Menzel <pmenzel@molgen.mpg.de>
>>>>>> Sent: Monday, March 21, 2022 16:25
>>>
>>> […]
>>>
>>>>> I seem to recall that we were talking about trying to drop the
>>>>> debounce delay for everything, weren't we?
>>>>>
>>>>> So perhaps it would be right to add a 4th patch in the series to do
>>>>> just that. Then If this turns out to be problematic for
>>>>> anything other than the controllers in the series that you
>>>>> identified as not problematic then that 4th patch can
>>>>> potentially be reverted alone?
>>>>
>>>> Not quite everything :) But you are right, let's try to switch the
>>>> default to no delay. I will be posting patches today for that.
>>>> With these patches, your patches are not necessary anymore as the AMD
>>>> chipset falls under the default no-delay.
>>>
>>> I am all for improving the situation for all devices, but I am unable to
>>> judge the regression potential of changing this, as it affects a lot of
>>> devices. I guess it’d would go through the next tree, and hopefully the
>>> company QA teams can give it a good spin. I hoped that my patches, as I
>>> have tested them, and AMD will hopefully too, could go into the current
>>> merge window.
>>
>> Yes, correct, the plan is to get the generic series queued as soon
>> as rc1 so that it can spend plenty of time in linux-next for people
>> to test. That will hopefully reduce the risk of breaking things in
>> the field. Same for the default LPM change.
>
> But 5.18 or 5.19? If 5.18, sounds good to me, if 5.19, I’d be great if
> my patches go into 5.18 cycle, as they have been tested, and it would
> mean the whole change gets tested more widely already.
>
>> With the default removal of the debounce delay, your patches addressing
>> only the AMD adapter are not needed anymore: this adapter will not have a
>> debounce delay unless the ATA_LFLAG_DEBOUNCE_DELAY flag is set.
>
> Yes, I understand.

The merge window for Linux 5.18 is going to close in three days this
Sunday. It’d be really great if my patches, tested on hardware, could go
into that.

>>>> It would be nice if you can test though.
>>>
>>> Of course, I am going to that either way.
>>
>> Series posted with you on CC. Please test !
>
> Thank you. I am going to test it in the coming days, and report back.
>
> Maybe more people should be put in Cc (Dell, Lenovo, IBM, x86 subsystem)
> with a request to test this?
Thank you for the patches, which are a big improvement. Let’s hope, you
can re-roll them, so they get into Linux very soon for everyone’s benefit.


Kind regards,

Paul

\
 
 \ /
  Last update: 2022-03-31 16:43    [W:0.080 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site