public inbox for linux-ide@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Werner Fischer <devlists@wefi.net>
Cc: "linux-ide@vger.kernel.org" <linux-ide@vger.kernel.org>
Subject: Re: [PATCH v2] ata: ahci: Add Elkhart Lake AHCI controller
Date: Fri, 1 Sep 2023 20:43:16 +0000	[thread overview]
Message-ID: <ZPJM4zlH3VZv0vxf@x1-carbon> (raw)
In-Reply-To: <4cbde7d33f5b73b33f798b56b6e3cd3ce3764647.camel@wefi.net>

On Tue, Aug 29, 2023 at 01:33:58PM +0200, Werner Fischer wrote:
> Elkhart Lake is the successor of Apollo Lake and Gemini Lake. These
> CPUs and their PCHs are used in mobile and embedded environments.
> 
> With this patch I suggest that Elkhart Lake SATA controllers [1] should
> use the default LPM policy for mobile chipsets.
> The disadvantage of missing hot-plug support with this setting should
> not be an issue, as those CPUs are used in embedded environments and
> not in servers with hot-plug backplanes.
> 
> We discovered that the Elkhart Lake SATA controllers have been missing
> in ahci.c after a customer reported the throttling of his SATA SSD
> after a short period of higher I/O. We determined the high temperature
> of the SSD controller in idle mode as the root cause for that.
> 
> Depending on the used SSD, we have seen up to 1.8 Watt lower system
> idle power usage and up to 30°C lower SSD controller temperatures in
> our tests, when we set med_power_with_dipm manually. I have provided a
> table showing seven different SATA SSDs from ATP, Intel/Solidigm and
> Samsung [2].
> 
> Intel lists a total of 3 SATA controller IDs (4B60, 4B62, 4B63) in [1]
> for those mobile PCHs.
> This commit just adds 0x4b63 as I do not have test systems with 0x4b60
> and 0x4b62 SATA controllers.
> I have tested this patch with a system which uses 0x4b63 as SATA
> controller.
> 
> [1] https://sata-io.org/product/8803
> [2] https://www.thomas-krenn.com/en/wiki/SATA_Link_Power_Management#Example_LES_v4
> 
> Signed-off-by: Werner Fischer <devlists@wefi.net>
> Cc: stable@vger.kernel.org
> ---
> V1 -> V2: Added comment mentioning the additional IDs 4b60 and 4b62
>           added "ahci:" in summary phrase
> 
> --- a/drivers/ata/ahci.c	2023-08-29 09:14:09.537450842 +0200
> +++ b/drivers/ata/ahci.c	2023-08-29 11:22:50.779830526 +0200
> @@ -421,6 +421,8 @@
>  	{ PCI_VDEVICE(INTEL, 0x34d3), board_ahci_low_power }, /* Ice Lake LP AHCI */
>  	{ PCI_VDEVICE(INTEL, 0x02d3), board_ahci_low_power }, /* Comet Lake PCH-U AHCI */
>  	{ PCI_VDEVICE(INTEL, 0x02d7), board_ahci_low_power }, /* Comet Lake PCH RAID */
> +	/* Elkhart Lake IDs 0x4b60 & 0x4b62 https://sata-io.org/product/8803 not tested yet */
> +	{ PCI_VDEVICE(INTEL, 0x4b63), board_ahci_low_power }, /* Elkhart Lake AHCI */
>  
>  	/* JMicron 360/1/3/5/6, match class to avoid IDE function */
>  	{ PCI_VENDOR_ID_JMICRON, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,

Damien,

considering that we have many Intel AHCI controllers using
board_ahci_low_power already, and we haven't heard any complaints
on those other than for Tiger Lake...

I guess we could accept this one as well, and hope that it is just
Intel Tiger Lake that is problematic.. I guess the only real way to
know if Elkhart Lake is problematic as well is to see if we hear
people complain...


(Yes, one problem with all AHCI controllers using board_ahci_low_power,
is that hotplug is not working if you use what many distros are using,
CONFIG_SATA_MOBILE_LPM_POLICY=3 or higher... but that is expected as
AHCI 1.3.1 section 7.3.1.1 clearly states that you need to disable both
partial and slumber states to have reliable hot plug detection.)


Kind regards,
Niklas

  reply	other threads:[~2023-09-01 20:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 11:33 [PATCH v2] ata: ahci: Add Elkhart Lake AHCI controller Werner Fischer
2023-09-01 20:43 ` Niklas Cassel [this message]
2023-09-02  3:09 ` Damien Le Moal
2023-09-06 13:02   ` Werner Fischer

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=ZPJM4zlH3VZv0vxf@x1-carbon \
    --to=niklas.cassel@wdc.com \
    --cc=devlists@wefi.net \
    --cc=linux-ide@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox