From patchwork Wed Mar 16 10:46:50 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jisheng Zhang X-Patchwork-Id: 8597671 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 42F06C0553 for ; Wed, 16 Mar 2016 10:51:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 320D7202F2 for ; Wed, 16 Mar 2016 10:51:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0C7892026C for ; Wed, 16 Mar 2016 10:51:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966205AbcCPKvb (ORCPT ); Wed, 16 Mar 2016 06:51:31 -0400 Received: from mx0a-0016f401.pphosted.com ([67.231.148.174]:30399 "EHLO mx0a-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965962AbcCPKvb (ORCPT ); Wed, 16 Mar 2016 06:51:31 -0400 Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2GAkXJ6032655; Wed, 16 Mar 2016 03:51:08 -0700 Received: from sc-exch04.marvell.com ([199.233.58.184]) by mx0a-0016f401.pphosted.com with ESMTP id 21mukf8dsp-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Mar 2016 03:51:05 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 16 Mar 2016 03:50:38 -0700 Received: from maili.marvell.com (10.93.176.43) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server id 15.0.1104.5 via Frontend Transport; Wed, 16 Mar 2016 03:50:38 -0700 Received: from xhacker (unknown [10.37.135.134]) by maili.marvell.com (Postfix) with ESMTP id 6F78E3F703F; Wed, 16 Mar 2016 03:50:37 -0700 (PDT) Date: Wed, 16 Mar 2016 18:46:50 +0800 From: Jisheng Zhang To: , , CC: , , Subject: Re: [PATCH] PCI: designware: move remaining rc setup code to dw_pcie_setup_rc() Message-ID: <20160316184650.1a88dba6@xhacker> In-Reply-To: <1458124582-2511-1-git-send-email-jszhang@marvell.com> References: <1458124582-2511-1-git-send-email-jszhang@marvell.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-16_04:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603160153 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Dear all, On Wed, 16 Mar 2016 18:36:22 +0800 Jisheng Zhang wrote: > dw_pcie_setup_rc(), as its name indicates, setups the RC. But current > dw_pcie_host_init() also contains some necessary rc setup code. > > Another reason: the host may lost power during suspend to ram, the RC > need to be re-setup after resume. The rc can't be correctly resumed > without the rc setup code in dw_pcie_host_init(). > > So this patch moves the code to dw_pcie_setup_rc() to address the above > two issues. After this patch, each pcie designware driver users could > call dw_pcie_setup_rc() to re-setup rc when resume back. Some background of this patch: we want to add suspend/resume support to BG4CT pcie hosts. The host will lost power when suspend to ram, and reset when resume back. So I must re-setup the rc by dw_pcie_setup_rc(). Tested on Marvell BG4CT platforms. Two issues need your help: 1. duplicate PCI_BASE_ADDRESS_0 programming. we first write 4 to PCI_BASE_ADDRESS_0 in dw_pcie_setup_rc(), then write 0 to it again in dw_pcie_host_init(). Is there any reason to do so? could we remove the latter PCI_BASE_ADDRESS_0 programming? 2. could we move the PORT_LOGIC_SPEED_CHANGE bit setting early, I.E with something as below: Thanks, Jisheng > > Signed-off-by: Jisheng Zhang > --- > drivers/pci/host/pcie-designware.c | 38 +++++++++++++++++++------------------- > 1 file changed, 19 insertions(+), 19 deletions(-) > > diff --git a/drivers/pci/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c > index a4cccd3..6474f80 100644 > --- a/drivers/pci/host/pcie-designware.c > +++ b/drivers/pci/host/pcie-designware.c > @@ -544,25 +544,6 @@ int dw_pcie_host_init(struct pcie_port *pp) > if (pp->ops->host_init) > pp->ops->host_init(pp); > > - /* > - * If the platform provides ->rd_other_conf, it means the platform > - * uses its own address translation component rather than ATU, so > - * we should not program the ATU here. > - */ > - if (!pp->ops->rd_other_conf) > - dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1, > - PCIE_ATU_TYPE_MEM, pp->mem_base, > - pp->mem_bus_addr, pp->mem_size); > - > - dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0); > - > - /* program correct class for RC */ > - dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI); > - > - dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val); > - val |= PORT_LOGIC_SPEED_CHANGE; > - dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val); > - > pp->root_bus_nr = pp->busn->start; > if (IS_ENABLED(CONFIG_PCI_MSI)) { > bus = pci_scan_root_bus_msi(pp->dev, pp->root_bus_nr, > @@ -800,6 +781,25 @@ void dw_pcie_setup_rc(struct pcie_port *pp) > val |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | > PCI_COMMAND_MASTER | PCI_COMMAND_SERR; > dw_pcie_writel_rc(pp, val, PCI_COMMAND); > + > + /* > + * If the platform provides ->rd_other_conf, it means the platform > + * uses its own address translation component rather than ATU, so > + * we should not program the ATU here. > + */ > + if (!pp->ops->rd_other_conf) > + dw_pcie_prog_outbound_atu(pp, PCIE_ATU_REGION_INDEX1, > + PCIE_ATU_TYPE_MEM, pp->mem_base, > + pp->mem_bus_addr, pp->mem_size); > + > + dw_pcie_wr_own_conf(pp, PCI_BASE_ADDRESS_0, 4, 0); > + > + /* program correct class for RC */ > + dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI); > + > + dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val); > + val |= PORT_LOGIC_SPEED_CHANGE; > + dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val); > } > > MODULE_AUTHOR("Jingoo Han "); --- 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/host/pcie-designware.c b/drivers/pci/host/pcie-designware.c index 6474f80..b824f6f 100644 --- a/drivers/pci/host/pcie-designware.c +++ b/drivers/pci/host/pcie-designware.c @@ -737,6 +737,7 @@ void dw_pcie_setup_rc(struct pcie_port *pp) /* set link width speed control register */ dw_pcie_readl_rc(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, &val); val &= ~PORT_LOGIC_LINK_WIDTH_MASK; + val |= PORT_LOGIC_SPEED_CHANGE; switch (pp->lanes) { case 1: val |= PORT_LOGIC_LINK_WIDTH_1_LANES; @@ -796,10 +797,6 @@ void dw_pcie_setup_rc(struct pcie_port *pp) /* program correct class for RC */ dw_pcie_wr_own_conf(pp, PCI_CLASS_DEVICE, 2, PCI_CLASS_BRIDGE_PCI); - - dw_pcie_rd_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, &val); - val |= PORT_LOGIC_SPEED_CHANGE; - dw_pcie_wr_own_conf(pp, PCIE_LINK_WIDTH_SPEED_CONTROL, 4, val); } MODULE_AUTHOR("Jingoo Han ");