From patchwork Sat Jun 14 21:21:26 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bjorn Helgaas X-Patchwork-Id: 359806 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id F32971400AB for ; Sun, 15 Jun 2014 07:21:28 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753308AbaFNVV2 (ORCPT ); Sat, 14 Jun 2014 17:21:28 -0400 Received: from mail-ig0-f172.google.com ([209.85.213.172]:45528 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753034AbaFNVV1 (ORCPT ); Sat, 14 Jun 2014 17:21:27 -0400 Received: by mail-ig0-f172.google.com with SMTP id l13so1645317iga.5 for ; Sat, 14 Jun 2014 14:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:to:from:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-type:content-transfer-encoding; bh=6DjooSF19hD46G+9oyRl/uoBq1QYMYifHxgMnUhhZow=; b=WT4nopx5UTPNfeHPZ9DiKCoLZUIvaqlXR50HVhkpleR4N3NcsWBVFga/NZirlcn32K UXoOfHfLzAVITHq/+tp5GYA+mwsvsuBv6lTJNfP6x28vGpT54iggDdRiytBDM/TqoHhn x+KDo5rdHxPxCwo2EtmaKD3/0lcP3RuLDtW4pwhOzj4ixLGnYYSbMPWXl1CuiskcK5bZ h3LZF22cT4s5AOr4209Up+GXa3cNUmP57Bf5vp+0S46k3fom3PFt98BcXmkTGz4pBkH2 Pk8P9ixQXrOAFeqjqZXeojgc8V9QS/HsjudwooIkifhy3384QxFOeGCHHzFVLGA3Xexl S8ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:from:cc:date:message-id:in-reply-to :references:user-agent:mime-version:content-type :content-transfer-encoding; bh=6DjooSF19hD46G+9oyRl/uoBq1QYMYifHxgMnUhhZow=; b=JjVZCalVP50gKwMclJ4ZmbHpfqJmgj9FKkzlpSCZpfuQ3hvJtL/8mqZO/suW3FKPsd pCZEZBg4yOW/BLlPjv12AZcxKl2CB1CpfFdyoksLZQMVI0mNvC1Yqs9lG/5Y0Sl7Z50J 22RVyaSdqYx3kZnM4LH08RpMry2ZBJW5ucaDKy2qs1NQJv7gvGEo+NymbKhQ2sK+wkkp KgVmA+czTJ8kV+ccwvqORRIb7PPNqzNj2IjUHdcFjOnMlyEWCok2us2aCy5JfnA1/Wk8 O2DXi9YhCuePX9ZPoDCNAhLQH5rdWEdkRBvjUaJ84Np4SX4fUJRSUJNGjNR+c0p3AOb0 eNSw== X-Gm-Message-State: ALoCoQlJqUjD34ojD5GqXA/BDVdX7QJHob/6SPyDAGjDqZ5F/4H1e1ZHGacJ1Ssdx0JVdCiRNX/+ X-Received: by 10.50.50.73 with SMTP id a9mr14296735igo.15.1402780887018; Sat, 14 Jun 2014 14:21:27 -0700 (PDT) Received: from localhost ([172.16.51.103]) by mx.google.com with ESMTPSA id cl7sm6638070igc.9.2014.06.14.14.21.26 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 14 Jun 2014 14:21:26 -0700 (PDT) Subject: [PATCH RFC 2/4] PCI: pciehp: Wait for hotplug command completion lazily To: Yinghai Lu From: Bjorn Helgaas Cc: "Jan C. Nordholz" , Kenji Kaneshige , Rajat Jain , linux-pci@vger.kernel.org Date: Sat, 14 Jun 2014 15:21:26 -0600 Message-ID: <20140614212126.15202.66060.stgit@bhelgaas-glaptop.roam.corp.google.com> In-Reply-To: <20140614210740.15202.84719.stgit@bhelgaas-glaptop.roam.corp.google.com> References: <20140614210740.15202.84719.stgit@bhelgaas-glaptop.roam.corp.google.com> User-Agent: StGit/0.16 MIME-Version: 1.0 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Previously we issued a hotplug command and waited for it to complete. But there's no need to wait until we're ready to issue the *next* command. The next command will probably be much later, so the first one may have already completed and we may not have to actually wait at all. Because of hardware errata, some controllers generate command completion events for some commands but not others. In the case of Intel CF118 (see spec update reference), the controller indicates command completion only for Slot Control writes that change the value of the following bits: Power Controller Control Power Indicator Control Attention Indicator Control Electromechanical Interlock Control Changes to other bits, e.g., the interrupt enable bits, do not cause the Command Completed bit to be set. Controllers from AMD and Nvidia are reported to have similar errata. These errata cause timeouts when pcie_enable_notification() enables interrupts. Previously that timeout occurred at boot-time. With this change, the timeout occurs later, when we change the state of the slot power, indicators, or interlock. This speeds up boot but causes a timeout at the first hotplug event on the slot. Subsequent events don't timeout because only the first (boot-time) hotplug command updates Slot Control without touching the power/indicator/interlock controls. Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html Signed-off-by: Bjorn Helgaas --- drivers/pci/hotplug/pciehp_hpc.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/hotplug/pciehp_hpc.c b/drivers/pci/hotplug/pciehp_hpc.c index 0e76e9d9d134..f44fdb5b0b08 100644 --- a/drivers/pci/hotplug/pciehp_hpc.c +++ b/drivers/pci/hotplug/pciehp_hpc.c @@ -165,6 +165,9 @@ static void pcie_write_cmd(struct controller *ctrl, u16 cmd, u16 mask) mutex_lock(&ctrl->ctrl_lock); + /* Wait for any previous command that might still be in progress */ + pcie_wait_cmd(ctrl); + pcie_capability_read_word(pdev, PCI_EXP_SLTSTA, &slot_status); if (slot_status & PCI_EXP_SLTSTA_CC) { pcie_capability_write_word(pdev, PCI_EXP_SLTSTA, @@ -197,10 +200,6 @@ static void pcie_write_cmd(struct controller *ctrl, u16 cmd, u16 mask) pcie_capability_write_word(pdev, PCI_EXP_SLTCTL, slot_ctrl); ctrl->slot_ctrl = slot_ctrl; - /* - * Wait for command completion. - */ - pcie_wait_cmd(ctrl); mutex_unlock(&ctrl->ctrl_lock); }