Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp5504321pxj; Wed, 26 May 2021 12:06:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyFZD2pvE3tXs30Hvz46tEisQmuKtYCoBtwsmzFq56gbyrlsqEXKmcVsw870ORwiKQfqyw4 X-Received: by 2002:a05:6402:190e:: with SMTP id e14mr39643852edz.146.1622055991923; Wed, 26 May 2021 12:06:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622055991; cv=none; d=google.com; s=arc-20160816; b=Bx1DqTtg0qYhNfQ2chFPFRvrSgpddKFvjfgBlOn6Ehovhhqgxh2E4hNbDpUGZzO09u kIUq+wtYE/tyVQ32V9xlEhGM9xsQnTphsEEpHejEZhUeoh6rqHYpR7TOPPQzzBOhJ/C4 RzhmVo80RPH/0HcojaxRQ4m8V/FamEzVKIk6KgmiGd3omOAg5pubGko4r+7KcW+mV80b B8d/qnuAxYpsjF96vvDSa87ZOlo5DLZVuZq+p334Nc8jjakWZK0t/4NC8HIGlZhB+YCG rWDZYe8IqFTQgExH2Mvxht6y+h3gSArQTNtwdeVKLE3+bGneglnSm1jcqX8NdcipfPPP 0xew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=EaLER3aOaefvnJohx084gatUZrVitp6/k9BAoBcbFwQ=; b=aDHekvjarELkK3CpCeF3COhAmSCRZw3ZL4Uqjk8eFmBGys6u53JH2y5N11q5+tzUgd d/jz6shgLcg3HCD5Cc8kzHJ6dt73hx0rG2y4LezYmBQtP6hlXf9ptkqGpLeY9bM0KEQU 5DnXU9wL3b1w2XkNhmU1Q99F6CnGJYTQyDcWpItzqfygLqyI/31YA8X8SGTImie2n+Iq NkMbInkKBy36YmRsxnbNGnXXCJ/4QP8+vF61P3wBecsSp4kQ/6e2GWzy+tMZbfxKUz+5 bMzgAQUzUtdldDtlAVeg6Vb3tOWRwg891ufwQbFLiK4V1/7sR0EafI+NcNIkwmCDGfbO aZAQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z7si165746edc.522.2021.05.26.12.06.06; Wed, 26 May 2021 12:06:31 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234104AbhEZQZw (ORCPT + 99 others); Wed, 26 May 2021 12:25:52 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:35277 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234191AbhEZQZw (ORCPT ); Wed, 26 May 2021 12:25:52 -0400 Received: from mail-lf1-f70.google.com ([209.85.167.70]) by youngberry.canonical.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1llwKR-0008Fd-J0 for linux-kernel@vger.kernel.org; Wed, 26 May 2021 16:24:19 +0000 Received: by mail-lf1-f70.google.com with SMTP id g25-20020a19e0590000b029022452ed1b20so843029lfj.5 for ; Wed, 26 May 2021 09:24:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EaLER3aOaefvnJohx084gatUZrVitp6/k9BAoBcbFwQ=; b=AbOd+YoAkmq3e7ZhZREw3PY6V5WuF6EC0pDWKDU1zhHT1U4E1a80RCWVjrAVM21nKn wEdOpWiOKZbWV4DyubLK9ExvY70Rfy7d6+WOARzk7LLNvdUDKvK2td6DCdTJ6IyeDx0G WUXzHGq+Oe9R+MuNtj0J2DSeUc3F59wFoKh1gDUqlcbXfAKqlrBwcNOivD/DR5da01Dt 7rGQo1gAiskyQhAO8XpnquMDUD8MJLOz1/gFaV8dqNlYx+hPmz7hoyEC1GXbDqPV2Bcr DUw5v+NyYly8KWB+kbf3f8jmpvZhYcXH5eVrFXlPeii4R62/gU7wH7AWbtcyRNTebttI BFfQ== X-Gm-Message-State: AOAM5330U4L7aVMNSdqZxDw8fx50v0OrhffaFEMIuI4Ef1ciylTJwjix HusmIjN4psK88QKGXtpXnMAybrCE8+tY18535rrNBoWnASak+fB/CAXHxBmd0FMc4CFG9++/gGt NoNCih2304WGf1yybiYpecefXTwJCtJXlX4nV2tyTlZEUKenW9joudMB6lQ== X-Received: by 2002:ac2:4144:: with SMTP id c4mr2630898lfi.425.1622046258902; Wed, 26 May 2021 09:24:18 -0700 (PDT) X-Received: by 2002:ac2:4144:: with SMTP id c4mr2630873lfi.425.1622046258620; Wed, 26 May 2021 09:24:18 -0700 (PDT) MIME-Version: 1.0 References: <20210526150633.GA1291513@bjorn-Precision-5520> In-Reply-To: <20210526150633.GA1291513@bjorn-Precision-5520> From: Kai-Heng Feng Date: Thu, 27 May 2021 00:24:06 +0800 Message-ID: Subject: Re: [PATCH] nvme-pci: Avoid to go into d3cold if device can't use npss. To: Bjorn Helgaas Cc: Christoph Hellwig , Keith Busch , Koba Ko , Jens Axboe , Sagi Grimberg , linux-nvme , Linux Kernel Mailing List , Henrik Juul Hansen , Bjorn Helgaas , Linux PCI Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 26, 2021 at 11:06 PM Bjorn Helgaas wrote: > > On Wed, May 26, 2021 at 10:47:13PM +0800, Kai-Heng Feng wrote: > > On Wed, May 26, 2021 at 10:28 PM Christoph Hellwig wrote: > > > On Wed, May 26, 2021 at 10:21:59PM +0800, Kai-Heng Feng wrote: > > > > To be fair, resuming the NVMe from D3hot is much slower than keep it > > > > at D0, which gives us a faster s2idle resume time. And now AMD also > > > > requires s2idle on their latest laptops. > > > > > > We'd much prefer to use it, but due to the broken platforms we can't > > > unfortunately. > > > > > > > And it's more like NVMe controllers don't respect PCI D3hot. > > > > > > What do you mean with that? > > > > Originally, we found that under s2idle, most NVMe controllers caused > > substantially more power if D3hot was used. > > We were told by all the major NVMe vendors that D3hot is not > > supported. > > What is this supposed to mean? PCIe r5.0, sec 5.3.1, says > > All Functions must support the D0 and D3 states (both D3Hot and D3Cold). > > Since D3hot is required for all functions, I don't think there is a > standard way to discover whether D3hot is supported. The PM > Capability (sec 7.5.2.1) has D1_Support and D2_Support bits, but no > D3_Support bit. > > Are the vendors just saying "sorry, our devices don't conform to the > spec"? Yes, that's exactly what they said. Because Windows Modern Standby always keep the NVMe at D0, so D3hot is untested by the vendors. NVMe vendors explicitly asked us to keep the NVMe controllers at D0 for s2idle. > > If what you really mean is "D3hot is supported and it works, but it > consumes more power than expected, If D3hot consumes more power than D0, is it really supported? > or the D3hot->D0 transition takes > longer than expected," that's a totally different thing, and you should > say *that*. The D3hot->D0 transition doesn't take longer than expected. It's just relatively slower than keeping the NVMe at D0. Kai-Heng > > Bjorn