mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul M Stillwell Jr <paul.m.stillwell.jr@intel.com>
To: Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jian-Hong Pan <jhp@endlessos.org>
Cc: "Bjorn Helgaas" <helgaas@kernel.org>,
	"Francisco Munoz" <francisco.munoz.ruiz@linux.intel.com>,
	"Johan Hovold" <johan@kernel.org>,
	"David Box" <david.e.box@linux.intel.com>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
	"Kuppuswamy Sathyanarayanan"
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	"Mika Westerberg" <mika.westerberg@linux.intel.com>,
	"Damien Le Moal" <dlemoal@kernel.org>,
	"Jonathan Derrick" <jonathan.derrick@linux.dev>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux@endlessos.org
Subject: Re: [PATCH v6 3/3] PCI: vmd: Drop resetting PCI bus action after scan mapped PCI child bus
Date: Mon, 24 Jun 2024 08:39:27 -0700	[thread overview]
Message-ID: <897ead26-be10-4bb3-b085-1b8c97d93964@intel.com> (raw)
In-Reply-To: <20240624082458.00006da1@linux.intel.com>

On 6/24/2024 8:24 AM, Nirmal Patel wrote:
> On Mon, 24 Jun 2024 16:21:45 +0800
> Jian-Hong Pan <jhp@endlessos.org> wrote:
> 
>> According to "PCIe r6.0, sec 5.5.4", before enabling ASPM L1.2 on the
>> PCIe Root Port and the child device, they should be programmed with
>> the same LTR1.2_Threshold value. However, they have different values
>> on VMD mapped PCI child bus. For example, Asus B1400CEAE's VMD mapped
>> PCI bridge and NVMe SSD controller have different LTR1.2_Threshold
>> values:
>>
>> 10000:e0:06.0 PCI bridge: Intel Corporation 11th Gen Core Processor
>> PCIe Controller (rev 01) (prog-if 00 [Normal decode]) ...
>>      Capabilities: [200 v1] L1 PM Substates
>>          L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+
>> L1_PM_Substates+ PortCommonModeRestoreTime=45us PortTPowerOnTime=50us
>>          L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1-
>>          	   T_CommonMode=45us LTR1.2_Threshold=101376ns
>>          L1SubCtl2: T_PwrOn=50us
>>
>> 10000:e1:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue
>> SN550 NVMe SSD (rev 01) (prog-if 02 [NVM Express]) ...
>>      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
>>
>> After debug in detail, both of the VMD mapped PCI bridge and the NVMe
>> SSD controller have been configured properly with the same
>> LTR1.2_Threshold value. But, become misconfigured after reset the VMD
>> mapped PCI bus which is introduced from commit 0a584655ef89 ("PCI:
>> vmd: Fix secondary bus reset for Intel bridges") and commit
>> 6aab5622296b ("PCI: vmd: Clean up domain before enumeration"). So,
>> drop the resetting PCI bus action after scan VMD mapped PCI child bus.
>>
>> Signed-off-by: Jian-Hong Pan <jhp@endlessos.org>
>> ---
>> v6:
>> - Introduced based on the discussion
>> https://lore.kernel.org/linux-pci/CAPpJ_efYWWxGBopbSQHB=Y2+1RrXFR2XWeqEhGTgdiw3XX0Jmw@mail.gmail.com/
>>
>>   drivers/pci/controller/vmd.c | 20 --------------------
>>   1 file changed, 20 deletions(-)
>>
>> diff --git a/drivers/pci/controller/vmd.c
>> b/drivers/pci/controller/vmd.c index 5309afbe31f9..af413cdb4f4e 100644
>> --- a/drivers/pci/controller/vmd.c
>> +++ b/drivers/pci/controller/vmd.c
>> @@ -793,7 +793,6 @@ static int vmd_enable_domain(struct vmd_dev *vmd,
>> unsigned long features) resource_size_t offset[2] = {0};
>>   	resource_size_t membar2_offset = 0x2000;
>>   	struct pci_bus *child;
>> -	struct pci_dev *dev;
>>   	int ret;
>>   
>>   	/*
>> @@ -935,25 +934,6 @@ static int vmd_enable_domain(struct vmd_dev
>> *vmd, unsigned long features) pci_scan_child_bus(vmd->bus);
>>   	vmd_domain_reset(vmd);
>>   
>> -	/* When Intel VMD is enabled, the OS does not discover the
>> Root Ports
>> -	 * owned by Intel VMD within the MMCFG space.
>> pci_reset_bus() applies
>> -	 * a reset to the parent of the PCI device supplied as
>> argument. This
>> -	 * is why we pass a child device, so the reset can be
>> triggered at
>> -	 * the Intel bridge level and propagated to all the children
>> in the
>> -	 * hierarchy.
>> -	 */
>> -	list_for_each_entry(child, &vmd->bus->children, node) {
>> -		if (!list_empty(&child->devices)) {
>> -			dev = list_first_entry(&child->devices,
>> -					       struct pci_dev,
>> bus_list);
>> -			ret = pci_reset_bus(dev);
>> -			if (ret)
>> -				pci_warn(dev, "can't reset device:
>> %d\n", ret); -
>> -			break;
>> -		}
>> -	}
>> -
>>   	pci_assign_unassigned_bus_resources(vmd->bus);
>>   
>>   	pci_walk_bus(vmd->bus, vmd_pm_enable_quirk, &features);
> 
> Thanks for the patch.
> 
> pci_reset_bus is required to avoid failure in vmd domain creation
> during multiple soft reboots test. So I believe we can't just remove
> it without proper testing. vmd_pm_enable_quirk happens after
> pci_reset_bus, then how is it resetting LTR1.2_Threshold value?
> 
> Thanks
> -nirmal

To follow up on what Nirmal said: why can't you set the threshold value 
in vmd_pm_enable_quirk() since we look at LTR there?

Paul


  reply	other threads:[~2024-06-24 15:39 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-24  8:11 [PATCH v6 0/3] PCI: vmd: Enable PCI PM's L1 substates of remapped PCIe Root Port and NVMe Jian-Hong Pan
2024-06-24  8:12 ` [PATCH v6 1/3] PCI: vmd: Set PCI devices to D0 before enable PCI PM's L1 substates Jian-Hong Pan
2024-06-24  8:17 ` [PATCH v6 2/3] PCI/ASPM: Add notes about enabling PCI-PM L1SS to pci_enable_link_state(_locked) Jian-Hong Pan
2024-06-24  8:21 ` [PATCH v6 3/3] PCI: vmd: Drop resetting PCI bus action after scan mapped PCI child bus Jian-Hong Pan
2024-06-24 15:24   ` Nirmal Patel
2024-06-24 15:39     ` Paul M Stillwell Jr [this message]
2024-06-25 10:31       ` Jian-Hong Pan
2024-06-25 20:32         ` Paul M Stillwell Jr
2024-06-25  9:52     ` Jian-Hong Pan
2024-06-25 19:42       ` Nirmal Patel

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=897ead26-be10-4bb3-b085-1b8c97d93964@intel.com \
    --to=paul.m.stillwell.jr@intel.com \
    --cc=david.e.box@linux.intel.com \
    --cc=dlemoal@kernel.org \
    --cc=francisco.munoz.ruiz@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=jhp@endlessos.org \
    --cc=johan@kernel.org \
    --cc=jonathan.derrick@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@endlessos.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=nirmal.patel@linux.intel.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    /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

all inboxes | Powered by JetHome®