From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
Mario Limonciello <Mario.Limonciello@amd.com>
Cc: Hans de Goede <hdegoede@redhat.com>,
linux-ide@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
Nehal-bakulchandra Shah <Nehal-bakulchandra.Shah@amd.com>
Subject: Re: [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300 Series Chipset SATA Controller
Date: Wed, 23 Mar 2022 17:24:33 +0900 [thread overview]
Message-ID: <d9837420-1cbb-ed5e-7043-985d9eb9d065@opensource.wdc.com> (raw)
In-Reply-To: <5fb6af7b-d84f-cbae-7eb1-543f3a7e53e4@molgen.mpg.de>
On 3/23/22 15:55, Paul Menzel wrote:
> Dear Damien,
>
>
> Am 23.03.22 um 06:01 schrieb Damien Le Moal:
>> On 3/22/22 06:51, Limonciello, Mario wrote:
>>> [Public]
>>>
>>>> -----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.
>>
>> Paul,
>>
>> 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.
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.
>
>> 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 !
>
>
> Kind regards,
>
> Paul
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2022-03-23 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-21 21:24 [PATCH v2 1/3] ata: ahci: Add new board low_power_no_debounce_delay Paul Menzel
2022-03-21 21:24 ` [PATCH v2 2/3] ata: ahci: Skip 200 ms debounce delay for AMD FCH SATA Controller Paul Menzel
2022-03-21 21:24 ` [PATCH v2 3/3] ata: ahci: Skip 200 ms debounce delay for AMD 300 Series Chipset " Paul Menzel
2022-03-21 21:51 ` Limonciello, Mario
2022-03-23 5:01 ` Damien Le Moal
2022-03-23 6:55 ` Paul Menzel
2022-03-23 8:24 ` Damien Le Moal [this message]
2022-03-23 8:36 ` Paul Menzel
2022-03-31 14:42 ` Paul Menzel
2022-03-31 23:04 ` Damien Le Moal
2022-04-01 5:18 ` Paul Menzel
2022-04-01 7:23 ` Damien Le Moal
2022-05-31 16:18 ` Paul Menzel
2022-05-31 16:21 ` Paul Menzel
2022-05-31 16:24 ` Paul Menzel
2022-06-01 8:58 ` Damien Le Moal
2022-08-30 9:05 ` Paul Menzel
2022-08-31 22:13 ` Damien Le Moal
2022-09-13 15:23 ` Paul Menzel
2022-09-13 15:28 ` Limonciello, Mario
2022-09-14 8:26 ` Damien Le Moal
2022-09-21 5:01 ` Damien Le Moal
2022-09-21 19:18 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9837420-1cbb-ed5e-7043-985d9eb9d065@opensource.wdc.com \
--to=damien.lemoal@opensource.wdc.com \
--cc=Mario.Limonciello@amd.com \
--cc=Nehal-bakulchandra.Shah@amd.com \
--cc=hdegoede@redhat.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.