Message ID | 20240130100050.14182-2-jhp@endlessos.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1111758dyb; Tue, 30 Jan 2024 02:04:57 -0800 (PST) X-Google-Smtp-Source: AGHT+IHRp60cf6yns6+oj8UmD3ZEo6bPZemNVn2wb3lOerNkyBZ7TWCdUw1diwoUMY6YBql0BV+3 X-Received: by 2002:a05:6214:d6a:b0:685:7e91:b423 with SMTP id 10-20020a0562140d6a00b006857e91b423mr9408829qvs.11.1706609097729; Tue, 30 Jan 2024 02:04:57 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706609097; cv=pass; d=google.com; s=arc-20160816; b=u1iRFc+kKXld8ohu4aXHv5F3w1MAnEmk7/FxaSCMT64gFOwZmXUSn4IOvPzoIZwMPA ftOm80O5lsWCzDC5sj/yGhDBFas6qd2rVVujBMAy2kogPUvh90cSdLuD4nzX2oyxWst3 9iy617YUKNnxjQc+kplIV/saoK8JAr5cu0xPHJwzH8Rj5eJKRuHRcO3U265vfX6HL1p1 FcU2M3PcC3UYbV3sUt/7m08wuJkJJoFGsBtVB6DjxSvtoXG9aN+oKrzmZoU5Vg8QCCXy IzN/hywfhE6NowcCBscVBRLZ3lUV5nUhB7pmQtMTC5BRunQq5F4TZa7LERZ+ri684Pkz tInw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=QKkQF0FpW08UeteOAoIxviKy11wOo5codk8APJXnHpw=; fh=tBTIidyhDS9E7J3McbqbZa3c/zGMWarlKyvCcJI/R8o=; b=PCEe/pn8HpruLUT3sqbw7HjMngrMVhUy5caAO8PWEbeQOUPUMulPvSklyQd68DIOIB FshGi5i7bVUPfKfy0mBybRSMo/LQsx+ZHD5NTEWYmJOaBXyaK8ZjKv6eLWRfhoLEmgac SxaOebJXRliaLRU7m8X7fMcTgWIvC2eCJFuM3WstyFF4ISjOxJ3sPHk0RdLtLSj4zEbJ swI9W+tUqKtlVI9zA6Cfl/OWbfF8gZ/N7PB2cDVhSLACu1kFxeEuZcslEBF8N/naL1xm WBmjuj36aOONX20jkWXquMW1xY3Ft/M3Umy90JckI+5pJH0KGSo8RhLWiiOWHr2l6zh4 B5hw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@endlessos.org header.s=google header.b=Pg8ZQJsu; arc=pass (i=1 spf=pass spfdomain=endlessos.org dkim=pass dkdomain=endlessos.org dmarc=pass fromdomain=endlessos.org); spf=pass (google.com: domain of linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=endlessos.org Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id i14-20020ad45c6e000000b00681b44eed98si9801224qvh.136.2024.01.30.02.04.57 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 02:04:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@endlessos.org header.s=google header.b=Pg8ZQJsu; arc=pass (i=1 spf=pass spfdomain=endlessos.org dkim=pass dkdomain=endlessos.org dmarc=pass fromdomain=endlessos.org); spf=pass (google.com: domain of linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-44343-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=endlessos.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 863961C26E97 for <ouuuleilei@gmail.com>; Tue, 30 Jan 2024 10:04:57 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9840F664AE; Tue, 30 Jan 2024 10:01:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=endlessos.org header.i=@endlessos.org header.b="Pg8ZQJsu" Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C87F65BBF for <linux-kernel@vger.kernel.org>; Tue, 30 Jan 2024 10:01:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706608901; cv=none; b=uWH/mkiwAR2dOBZfsxVFHXbIzxPrIpekyUd1RSbrjebaPbadvPbNzZYuCylz0lVzXOV3G3DPgxUv5EVuUQi4Uhn4vRidr/rAzaXm5Jc8vSu69VG7dng5Z3CLTeHNsWaCZWGlnXSQyAXshw9vFKQzhA1zbnzSQ/RMIcf5p8NJHAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706608901; c=relaxed/simple; bh=teXt9OHZdZez3wzxIY3fbH5xLvmsOi4Wj5q2dFRSqx0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=p0xMCQT1UKtTlf7Iq+lWWqjOHy651ehRZhD+safqo0FCJQZzt/hnAcmJI1zprBUCj74ykXVCuDVGxeoyJHHt2mPn7ELPav0XxyGZ7bZoY5FZXFFQPEwQZDfqnxaJfMBm2G60ak2pMQ+8uyn4bM9ihyHs/c3532/oTzLSl6QTeyw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=endlessos.org; spf=pass smtp.mailfrom=endlessos.org; dkim=pass (2048-bit key) header.d=endlessos.org header.i=@endlessos.org header.b=Pg8ZQJsu; arc=none smtp.client-ip=209.85.216.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=endlessos.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=endlessos.org Received: by mail-pj1-f49.google.com with SMTP id 98e67ed59e1d1-2901f9ea918so1738972a91.3 for <linux-kernel@vger.kernel.org>; Tue, 30 Jan 2024 02:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endlessos.org; s=google; t=1706608900; x=1707213700; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=QKkQF0FpW08UeteOAoIxviKy11wOo5codk8APJXnHpw=; b=Pg8ZQJsuOIKrKWAPtAdwj5JEMcqmwByEUHyPkHoyIeI6rd8cAgKB7dODgs4H37vWof UZOFF+qg83yKXNm1ar+ZncH5VL0C3KU6guVI3nVf41V1ZP/Jk+AXXD/rI5uO75TBa3uW slx4fV5rysnvznkjxxcVw+4lhidKLB5fVCWSF+yFSw+FX6wEe25t4qnKtte8gSAhuCL2 7egLUuUH77GBRVIvWT8XnkT3pDanYR/kS1iUTpA7k8wC21NL3UZavlf+0PuD9i/elSvP 7FKO+zU5JD6DSaHcSVCv3zMMXywKe4Sq9+A9jfjgYkuTNyaoYy8EmHIzYB98d2R6Fvab jzAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706608900; x=1707213700; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QKkQF0FpW08UeteOAoIxviKy11wOo5codk8APJXnHpw=; b=UXDpalcLYmRYTtnZp7irnpcD4K6+pKEyhXgsppE9xyYlnUPUhsl9nn3moob2QX8UI6 mA4ldJwafv297WFTOSnVAeN3m0zocwV0Ms+Ey3c0DSEQ/5ukLDlvE4mdtExMLlSoaN+A Tm731tpJWLlIyOsAAAaZWYkS+BYtCr0rmFwWUHJhqxqaXcmkC0AD6KHNyKOGMEHAf47m h8n961bHPQCF+z50lzQ8dEsHTQMlP4zy5rWR8GZqJupIvpERB+zJmDcvJW2RAAy1QP2v 8lNf5kw77Tlknyhw6Pvh4R06/jPdCxfCk3iF0B/1//1AbL26KqPVFcy1oL2NYflfFkCe X3LQ== X-Gm-Message-State: AOJu0Yw0KxtQ55pyGUcihePwPqLfaGNG8K5ZU1HLNiEkkrwUyUlZvMiG 72kex97DtQTOXS2BDR87189nFBMPIAyYvU1nTAGJzIF/psZ8KtVb4zvLytGWlSE= X-Received: by 2002:a17:90a:604f:b0:295:b7d0:eadc with SMTP id h15-20020a17090a604f00b00295b7d0eadcmr456213pjm.24.1706608899779; Tue, 30 Jan 2024 02:01:39 -0800 (PST) Received: from localhost.localdomain ([123.51.167.56]) by smtp.googlemail.com with ESMTPSA id sg14-20020a17090b520e00b00295bc312ceasm730672pjb.34.2024.01.30.02.01.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 02:01:39 -0800 (PST) From: Jian-Hong Pan <jhp@endlessos.org> To: Mika Westerberg <mika.westerberg@linux.intel.com>, David Box <david.e.box@linux.intel.com>, Damien Le Moal <dlemoal@kernel.org>, Niklas Cassel <cassel@kernel.org>, Nirmal Patel <nirmal.patel@linux.intel.com>, Jonathan Derrick <jonathan.derrick@linux.dev> Cc: linux-ide@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux@endlessos.org, Jian-Hong Pan <jhp@endlessos.org> Subject: [PATCH 2/2] PCI: vmd: enable PCI PM's L1 substates of remapped PCIe port and NVMe Date: Tue, 30 Jan 2024 18:00:51 +0800 Message-ID: <20240130100050.14182-2-jhp@endlessos.org> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789509340790715719 X-GMAIL-MSGID: 1789509340790715719 |
Series |
[1/2] ata: ahci: Add force LPM policy quirk for ASUS B1400CEAE
|
|
Commit Message
Jian-Hong Pan
Jan. 30, 2024, 10 a.m. UTC
The remmapped PCIe port and NVMe have PCI PM L1 substates capability on
ASUS B1400CEAE, but they are disabled originally:
Capabilities: [900 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
PortCommonModeRestoreTime=32us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=10us
Power on all of the VMD remapped PCI devices before enable PCI-PM L1 PM
Substates by following "Section 5.5.4 of PCIe Base Spec Revision 5.0
Version 0.1". Then, PCI PM's L1 substates control are enabled
accordingly.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394
Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
---
drivers/pci/controller/vmd.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
Comments
Capitalize subject line to match history ("Enable PM L1 Substates ...") On Tue, Jan 30, 2024 at 06:00:51PM +0800, Jian-Hong Pan wrote: > The remmapped PCIe port and NVMe have PCI PM L1 substates capability on > ASUS B1400CEAE, but they are disabled originally: s/remmapped/remapped/ s/PCIe port/PCIe Root Port/ (all devices with Links have Ports, so we can be a little more specific here) I doubt "ASUS B1400CEAE" is relevant here. > Capabilities: [900 v1] L1 PM Substates > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ > PortCommonModeRestoreTime=32us PortTPowerOnTime=10us > L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- > T_CommonMode=0us LTR1.2_Threshold=0ns > L1SubCtl2: T_PwrOn=10us > > Power on all of the VMD remapped PCI devices before enable PCI-PM L1 PM > Substates by following "Section 5.5.4 of PCIe Base Spec Revision 5.0 > Version 0.1". Then, PCI PM's L1 substates control are enabled > accordingly. Reference PCIe r6.0 or r6.1, since r5.0 is almost 5 years old now. > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394 > Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> > --- > drivers/pci/controller/vmd.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c > index 87b7856f375a..b1bbe8e6075a 100644 > --- a/drivers/pci/controller/vmd.c > +++ b/drivers/pci/controller/vmd.c > @@ -738,6 +738,12 @@ static void vmd_copy_host_bridge_flags(struct pci_host_bridge *root_bridge, > vmd_bridge->native_dpc = root_bridge->native_dpc; > } > > +static int vmd_power_on_pci_device(struct pci_dev *pdev, void *userdata) > +{ > + pci_set_power_state(pdev, PCI_D0); > + return 0; > +} > + > /* > * Enable ASPM and LTR settings on devices that aren't configured by BIOS. > */ > @@ -928,6 +934,13 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) > vmd_acpi_begin(); > > pci_scan_child_bus(vmd->bus); > + > + /* > + * Make PCI devices at D0 when enable PCI-PM L1 PM Substates from > + * Section 5.5.4 of PCIe Base Spec Revision 5.0 Version 0.1 > + */ > + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL); Sec 5.5.4 indeed says "If setting either or both of the enable bits for PCI-PM L1 PM Substates, both ports must be configured ... while in D0." This applies to *all* PCIe devices, not just those below a VMD bridge, so I'm not sure this is the right place to do this. Is there anything that prevents a similar issue for non-VMD hierarchies? I guess the bridges (Root Ports and Switch Ports) must already be in D0, or we wouldn't be able to enumerate anything below them, right? It would be nice to connect this more closely with the L1 PM Substates configuration. I don't quite see the connection here. The only path I see for L1SS configuration is this: pci_scan_slot pcie_aspm_init_link_state pcie_aspm_cap_init aspm_l1ss_init which of course is inside pci_scan_child_bus(), which happens *before* this patch puts the devices in D0. Where does the L1SS configuration happen after this vmd_power_on_pci_device()? > vmd_domain_reset(vmd); > > /* When Intel VMD is enabled, the OS does not discover the Root Ports > -- > 2.43.0 >
[+cc Johan since qcom has similar code] On Tue, Jan 30, 2024 at 10:35:19AM -0600, Bjorn Helgaas wrote: > On Tue, Jan 30, 2024 at 06:00:51PM +0800, Jian-Hong Pan wrote: > > The remmapped PCIe port and NVMe have PCI PM L1 substates capability on > > ASUS B1400CEAE, but they are disabled originally: > > > > Capabilities: [900 v1] L1 PM Substates > > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ > > PortCommonModeRestoreTime=32us PortTPowerOnTime=10us > > L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- > > T_CommonMode=0us LTR1.2_Threshold=0ns > > L1SubCtl2: T_PwrOn=10us > > > > Power on all of the VMD remapped PCI devices before enable PCI-PM L1 PM > > Substates by following "Section 5.5.4 of PCIe Base Spec Revision 5.0 > > Version 0.1". Then, PCI PM's L1 substates control are enabled > > accordingly. > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394 > > Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> > > --- > > drivers/pci/controller/vmd.c | 13 +++++++++++++ > > 1 file changed, 13 insertions(+) > > > > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c > > index 87b7856f375a..b1bbe8e6075a 100644 > > --- a/drivers/pci/controller/vmd.c > > +++ b/drivers/pci/controller/vmd.c > > @@ -738,6 +738,12 @@ static void vmd_copy_host_bridge_flags(struct pci_host_bridge *root_bridge, > > vmd_bridge->native_dpc = root_bridge->native_dpc; > > } > > > > +static int vmd_power_on_pci_device(struct pci_dev *pdev, void *userdata) > > +{ > > + pci_set_power_state(pdev, PCI_D0); > > + return 0; > > +} > > + > > /* > > * Enable ASPM and LTR settings on devices that aren't configured by BIOS. > > */ > > @@ -928,6 +934,13 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) > > vmd_acpi_begin(); > > > > pci_scan_child_bus(vmd->bus); > > + > > + /* > > + * Make PCI devices at D0 when enable PCI-PM L1 PM Substates from > > + * Section 5.5.4 of PCIe Base Spec Revision 5.0 Version 0.1 > > + */ > > + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL); > > Sec 5.5.4 indeed says "If setting either or both of the enable bits > for PCI-PM L1 PM Substates, both ports must be configured ... while in > D0." > > This applies to *all* PCIe devices, not just those below a VMD bridge, > so I'm not sure this is the right place to do this. Is there anything > that prevents a similar issue for non-VMD hierarchies? > > I guess the bridges (Root Ports and Switch Ports) must already be in > D0, or we wouldn't be able to enumerate anything below them, right? > > It would be nice to connect this more closely with the L1 PM Substates > configuration. I don't quite see the connection here. The only path > I see for L1SS configuration is this: > > pci_scan_slot > pcie_aspm_init_link_state > pcie_aspm_cap_init > aspm_l1ss_init > > which of course is inside pci_scan_child_bus(), which happens *before* > this patch puts the devices in D0. Where does the L1SS configuration > happen after this vmd_power_on_pci_device()? I think I found it; a more complete call tree is like this, where the L1SS configuration is inside the pci_enable_link_state_locked() done by the vmd_pm_enable_quirk() bus walk: vmd_enable_domain pci_scan_child_bus ... pci_scan_slot pcie_aspm_init_link_state pcie_aspm_cap_init aspm_l1ss_init + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL) ... pci_walk_bus(vmd->bus, vmd_pm_enable_quirk, &features) vmd_pm_enable_quirk pci_enable_link_state_locked(PCIE_LINK_STATE_ALL) __pci_enable_link_state link->aspm_default |= ... pcie_config_aspm_link pcie_config_aspm_l1ss pci_clear_and_set_config_dword(PCI_L1SS_CTL1) # <-- pcie_config_aspm_dev pcie_capability_clear_and_set_word(PCI_EXP_LNKCTL) qcom_pcie_enable_aspm() does a similar pci_set_power_state(PCI_D0) before calling pci_enable_link_state_locked(). I would prefer to avoid the D0 precondition, but at the very least, I think we should add a note to the pci_enable_link_state_locked() kernel-doc saying the caller must ensure the device is in D0. I think vmd_pm_enable_quirk() is also problematic because it configures the LTR Capability *after* calling pci_enable_link_state_locked(PCIE_LINK_STATE_ALL). The pci_enable_link_state_locked() will enable ASPM L1.2, but sec 5.5.4 says LTR_L1.2_THRESHOLD must be programmed *before* ASPM L1.2 Enable is set. Bjorn
Bjorn Helgaas <helgaas@kernel.org> 於 2024年1月31日 週三 上午1:28寫道: > > [+cc Johan since qcom has similar code] > > On Tue, Jan 30, 2024 at 10:35:19AM -0600, Bjorn Helgaas wrote: > > On Tue, Jan 30, 2024 at 06:00:51PM +0800, Jian-Hong Pan wrote: > > > The remmapped PCIe port and NVMe have PCI PM L1 substates capability on > > > ASUS B1400CEAE, but they are disabled originally: > > > > > > Capabilities: [900 v1] L1 PM Substates > > > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ > > > PortCommonModeRestoreTime=32us PortTPowerOnTime=10us > > > L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- > > > T_CommonMode=0us LTR1.2_Threshold=0ns > > > L1SubCtl2: T_PwrOn=10us > > > > > > Power on all of the VMD remapped PCI devices before enable PCI-PM L1 PM > > > Substates by following "Section 5.5.4 of PCIe Base Spec Revision 5.0 > > > Version 0.1". Then, PCI PM's L1 substates control are enabled > > > accordingly. > > > > > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=218394 > > > Signed-off-by: Jian-Hong Pan <jhp@endlessos.org> > > > --- > > > drivers/pci/controller/vmd.c | 13 +++++++++++++ > > > 1 file changed, 13 insertions(+) > > > > > > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c > > > index 87b7856f375a..b1bbe8e6075a 100644 > > > --- a/drivers/pci/controller/vmd.c > > > +++ b/drivers/pci/controller/vmd.c > > > @@ -738,6 +738,12 @@ static void vmd_copy_host_bridge_flags(struct pci_host_bridge *root_bridge, > > > vmd_bridge->native_dpc = root_bridge->native_dpc; > > > } > > > > > > +static int vmd_power_on_pci_device(struct pci_dev *pdev, void *userdata) > > > +{ > > > + pci_set_power_state(pdev, PCI_D0); > > > + return 0; > > > +} > > > + > > > /* > > > * Enable ASPM and LTR settings on devices that aren't configured by BIOS. > > > */ > > > @@ -928,6 +934,13 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) > > > vmd_acpi_begin(); > > > > > > pci_scan_child_bus(vmd->bus); > > > + > > > + /* > > > + * Make PCI devices at D0 when enable PCI-PM L1 PM Substates from > > > + * Section 5.5.4 of PCIe Base Spec Revision 5.0 Version 0.1 > > > + */ > > > + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL); > > > > Sec 5.5.4 indeed says "If setting either or both of the enable bits > > for PCI-PM L1 PM Substates, both ports must be configured ... while in > > D0." > > > > This applies to *all* PCIe devices, not just those below a VMD bridge, > > so I'm not sure this is the right place to do this. Is there anything > > that prevents a similar issue for non-VMD hierarchies? > > > > I guess the bridges (Root Ports and Switch Ports) must already be in > > D0, or we wouldn't be able to enumerate anything below them, right? > > > > It would be nice to connect this more closely with the L1 PM Substates > > configuration. I don't quite see the connection here. The only path > > I see for L1SS configuration is this: > > > > pci_scan_slot > > pcie_aspm_init_link_state > > pcie_aspm_cap_init > > aspm_l1ss_init > > > > which of course is inside pci_scan_child_bus(), which happens *before* > > this patch puts the devices in D0. Where does the L1SS configuration > > happen after this vmd_power_on_pci_device()? > > I think I found it; a more complete call tree is like this, where the > L1SS configuration is inside the pci_enable_link_state_locked() done > by the vmd_pm_enable_quirk() bus walk: > > vmd_enable_domain > pci_scan_child_bus > ... > pci_scan_slot > pcie_aspm_init_link_state > pcie_aspm_cap_init > aspm_l1ss_init > + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL) > ... > pci_walk_bus(vmd->bus, vmd_pm_enable_quirk, &features) > vmd_pm_enable_quirk > pci_enable_link_state_locked(PCIE_LINK_STATE_ALL) > __pci_enable_link_state > link->aspm_default |= ... > pcie_config_aspm_link > pcie_config_aspm_l1ss > pci_clear_and_set_config_dword(PCI_L1SS_CTL1) # <-- > pcie_config_aspm_dev > pcie_capability_clear_and_set_word(PCI_EXP_LNKCTL) > > qcom_pcie_enable_aspm() does a similar pci_set_power_state(PCI_D0) > before calling pci_enable_link_state_locked(). I would prefer to > avoid the D0 precondition, but at the very least, I think we should > add a note to the pci_enable_link_state_locked() kernel-doc saying the > caller must ensure the device is in D0. > > I think vmd_pm_enable_quirk() is also problematic because it > configures the LTR Capability *after* calling > pci_enable_link_state_locked(PCIE_LINK_STATE_ALL). > > The pci_enable_link_state_locked() will enable ASPM L1.2, but sec > 5.5.4 says LTR_L1.2_THRESHOLD must be programmed *before* ASPM L1.2 > Enable is set. Thanks! This inspires me why LTR1.2_Threshold is 0ns here. Jian-Hong Pan
On Tue, Jan 30, 2024 at 06:00:51PM +0800, Jian-Hong Pan wrote: > The remmapped PCIe port and NVMe have PCI PM L1 substates capability on > ASUS B1400CEAE, but they are disabled originally: > > Capabilities: [900 v1] L1 PM Substates > L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ > PortCommonModeRestoreTime=32us PortTPowerOnTime=10us > L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- > T_CommonMode=0us LTR1.2_Threshold=0ns > L1SubCtl2: T_PwrOn=10us > > Power on all of the VMD remapped PCI devices before enable PCI-PM L1 PM > Substates by following "Section 5.5.4 of PCIe Base Spec Revision 5.0 > Version 0.1". Then, PCI PM's L1 substates control are enabled > accordingly. > +static int vmd_power_on_pci_device(struct pci_dev *pdev, void *userdata) > +{ > + pci_set_power_state(pdev, PCI_D0); As I believe Bjorn already hinted at, this should probably be done in vmd_pm_enable_quirk(). Also, you need to use the new pci_set_power_state_locked() helper since these callbacks are called from pci_walk_bus() with the bus semaphore held: https://lore.kernel.org/lkml/20240130100243.11011-1-johan+linaro@kernel.org/ > + return 0; > +} > + > /* > * Enable ASPM and LTR settings on devices that aren't configured by BIOS. > */ > @@ -928,6 +934,13 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) > vmd_acpi_begin(); > > pci_scan_child_bus(vmd->bus); > + > + /* > + * Make PCI devices at D0 when enable PCI-PM L1 PM Substates from > + * Section 5.5.4 of PCIe Base Spec Revision 5.0 Version 0.1 > + */ > + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL); > + > vmd_domain_reset(vmd); > > /* When Intel VMD is enabled, the OS does not discover the Root Ports Johan
diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c index 87b7856f375a..b1bbe8e6075a 100644 --- a/drivers/pci/controller/vmd.c +++ b/drivers/pci/controller/vmd.c @@ -738,6 +738,12 @@ static void vmd_copy_host_bridge_flags(struct pci_host_bridge *root_bridge, vmd_bridge->native_dpc = root_bridge->native_dpc; } +static int vmd_power_on_pci_device(struct pci_dev *pdev, void *userdata) +{ + pci_set_power_state(pdev, PCI_D0); + return 0; +} + /* * Enable ASPM and LTR settings on devices that aren't configured by BIOS. */ @@ -928,6 +934,13 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features) vmd_acpi_begin(); pci_scan_child_bus(vmd->bus); + + /* + * Make PCI devices at D0 when enable PCI-PM L1 PM Substates from + * Section 5.5.4 of PCIe Base Spec Revision 5.0 Version 0.1 + */ + pci_walk_bus(vmd->bus, vmd_power_on_pci_device, NULL); + vmd_domain_reset(vmd); /* When Intel VMD is enabled, the OS does not discover the Root Ports