From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13AAAC433EF for ; Fri, 12 Nov 2021 00:38:44 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D0FFA601FF for ; Fri, 12 Nov 2021 00:38:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D0FFA601FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8QCG5oVa9Xr4fMeyo1+XSVLK2izE3E1w0MwAkXvxw24=; b=NFDKmrZSJK7IVH g2Z5L4xhG8gB/68tDDeB3GnIdIRoHjVoFoZWJDAICC8QQ9JavLNsxicXR5Ec1xRHlAdLQfFM+Nmke QLwc0qGO/6YdtKM6fiLUnQAMnE3lo2nN5imIz1NY/aVsfUeGDQDIjCfJHBOA7MbukGPx6QPH1ogst 3qgzqXSr3L8w+tmQh8ZRLlqaHlnYz+yBxc0Wy0fRWnpg5/p0JZi6g8WI9QNnAFJ5sOnMQ/L8pUDTQ TcnCypJkCMyYBQCKGoyfzkjokaHj+sxDiaqutj6qcTyjRufsanI4deRnbc2uvwwPB8B7h8pUFqVXB LMwPMtK+Ljf6UDaoS3Fw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mlKZ9-0094Uy-BY; Fri, 12 Nov 2021 00:37:15 +0000 Received: from mail-ed1-f54.google.com ([209.85.208.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mlKZ4-0094To-6t for linux-arm-kernel@lists.infradead.org; Fri, 12 Nov 2021 00:37:11 +0000 Received: by mail-ed1-f54.google.com with SMTP id m14so31149982edd.0 for ; Thu, 11 Nov 2021 16:37:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=R1tUfUsW9yxfyVmNsT2W35onz8Yo0bOTMnqcIJ1wUhc=; b=bS8/cOeeA3Fww5iYmIZN987cp13P5Tr5NjUYL/pBYLAPuUcPJyu/HEHoegjGJOEzwx whYMOrvzv+S7esWwhvpTzeZZoo7EulYNqN/YIIbav84Ve2uCmlAkfocv8iFxBQNg0VOw ClVNHZxDQwyPpDjMYQMzwez9MLlS/SatBJxmZvnLGP3zcgHzYks+NXXvtbYCiT5wAA9y 6DJdcRzt4dONYGNmKuD+2ID9sZ8kDbliHg+PeLs6trkIrcxJBL/hRH9HuV2aIM71IReo PhBWc3lq1sAMYQJFEpdeOQcNVBtRn/bDYgHR2fBxzQMyh3rRfaSQ5UQIIClQeLFz0Y9a +0dg== X-Gm-Message-State: AOAM531pTE7UfkEYlKp5T2GR1VxXo9OSLAu5kF/t/gyM4mrVWdS/u2ev nVQlHoU87fhz8qTdWYiKoJE= X-Google-Smtp-Source: ABdhPJwPnxK6FC4BIfe/lkhIF828ja5edt407OTCenhE6XVpenIhvw+b0OdNEv6X6UuF4fuzGcyDiw== X-Received: by 2002:a50:f08b:: with SMTP id v11mr15560307edl.96.1636677427655; Thu, 11 Nov 2021 16:37:07 -0800 (PST) Received: from rocinante ([95.155.85.46]) by smtp.gmail.com with ESMTPSA id h6sm794056edz.40.2021.11.11.16.37.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 16:37:07 -0800 (PST) Date: Fri, 12 Nov 2021 01:37:05 +0100 From: Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= To: Zhiqiang Hou Cc: linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, lorenzo.pieralisi@arm.com, robh+dt@kernel.org, bhelgaas@google.com, shawnguo@kernel.org, leoyang.li@nxp.com, gustavo.pimentel@synopsys.com, minghuan.Lian@nxp.com, mingkai.hu@nxp.com, roy.zang@nxp.com Subject: Re: [PATCHv5 6/6] PCI: layerscape: Add power management support Message-ID: References: <20210407030948.3845-1-Zhiqiang.Hou@nxp.com> <20210407030948.3845-7-Zhiqiang.Hou@nxp.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210407030948.3845-7-Zhiqiang.Hou@nxp.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211111_163710_312493_BAF66A48 X-CRM114-Status: GOOD ( 22.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, [...] > +/* PF Message Command Register */ > +#define LS_PCIE_PF_MCR 0x2c > +#define PF_MCR_PTOMR BIT(0) > +#define PF_MCR_EXL2S BIT(1) > + > +/* LS1021A PEXn PM Write Control Register */ > +#define SCFG_PEXPMWRCR(idx) (0x5c + (idx) * 0x64) > +#define PMXMTTURNOFF BIT(31) > +#define SCFG_PEXSFTRSTCR 0x190 > +#define PEXSR(idx) BIT(idx) > + > +/* LS1043A PEX PME control register */ > +#define SCFG_PEXPMECR 0x144 > +#define PEXPME(idx) BIT(31 - (idx) * 4) > + > +/* LS1043A PEX LUT debug register */ > +#define LS_PCIE_LDBG 0x7fc > +#define LDBG_SR BIT(30) > +#define LDBG_WE BIT(31) A small nitpick: a consistent capitalisation of "control" and "debug", and "register" in the comments above. [...] > +static void ls_pcie_lut_writel(struct ls_pcie *pcie, u32 off, u32 val) > +{ > + if (pcie->big_endian) > + return iowrite32be(val, pcie->lut_base + off); > + > + return iowrite32(val, pcie->lut_base + off); > + > +} Surplus newline above after the return statement. [...] > +static void ls_pcie_pf_writel(struct ls_pcie *pcie, u32 off, u32 val) > +{ > + if (pcie->big_endian) > + return iowrite32be(val, pcie->pf_base + off); > + > + return iowrite32(val, pcie->pf_base + off); > + > +} Surplus newline above after the return statement. [...] > +static void ls_pcie_send_turnoff_msg(struct ls_pcie *pcie) > +{ > + u32 val; > + int ret; > + > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR); > + val |= PF_MCR_PTOMR; > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val); > + > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR, > + val, !(val & PF_MCR_PTOMR), 100, 10000); > + if (ret) > + dev_info(pcie->pci->dev, "poll turn off message timeout\n"); > +} Would this dev_info() be more of a warning or an error? A timeout is potentially a problem, correct? [...] > +static void ls1021a_pcie_send_turnoff_msg(struct ls_pcie *pcie) > +{ > + u32 val; > + > + if (!pcie->scfg) { > + dev_dbg(pcie->pci->dev, "SYSCFG is NULL\n"); > + return; > + } > + > + /* Send Turn_off message */ > + regmap_read(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), &val); > + val |= PMXMTTURNOFF; > + regmap_write(pcie->scfg, SCFG_PEXPMWRCR(pcie->index), val); > + > + mdelay(10); We often, customary, document why a particular mdelay() is needed. You also did this in other part of the code, so perhaps adding a note here (and everywhere else) would be nice for keeping the consistency. [...] > +static void ls_pcie_exit_from_l2(struct ls_pcie *pcie) > +{ > + u32 val; > + int ret; > + > + val = ls_pcie_pf_readl(pcie, LS_PCIE_PF_MCR); > + val |= PF_MCR_EXL2S; > + ls_pcie_pf_writel(pcie, LS_PCIE_PF_MCR, val); > + > + ret = readx_poll_timeout(ls_pcie_pf_readl_addr, LS_PCIE_PF_MCR, > + val, !(val & PF_MCR_EXL2S), 100, 10000); > + if (ret) > + dev_info(pcie->pci->dev, "poll exit L2 state timeout\n"); > +} Similarly to the question above: is this timeout something more severe and would warrant a warning or an error here instead? [...] > +static void ls1021a_pcie_exit_from_l2(struct ls_pcie *pcie) > +{ > + u32 val; > + > + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val); > + val |= PEXSR(pcie->index); > + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val); > + > + regmap_read(pcie->scfg, SCFG_PEXSFTRSTCR, &val); > + val &= ~PEXSR(pcie->index); > + regmap_write(pcie->scfg, SCFG_PEXSFTRSTCR, val); > + > + mdelay(1); Aside of documenting this mdelay() here, if possible, would 1 be enough? Everywhere else you seem to use 10 consistently. > + > + ls_pcie_retrain_link(pcie); > +} > +static void ls1043a_pcie_exit_from_l2(struct ls_pcie *pcie) Missing newline above to separate code blocks. > +{ > + u32 val; > + > + val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG); > + val |= LDBG_WE; > + ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val); > + > + val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG); > + val |= LDBG_SR; > + ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val); > + > + val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG); > + val &= ~LDBG_SR; > + ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val); > + > + val = ls_pcie_lut_readl(pcie, LS_PCIE_LDBG); > + val &= ~LDBG_WE; > + ls_pcie_lut_writel(pcie, LS_PCIE_LDBG, val); > + > + mdelay(1); See comment above. [...] > +static int ls1021a_pcie_pm_init(struct ls_pcie *pcie) > +{ > + struct device *dev = pcie->pci->dev; > + u32 index[2]; > + int ret; > + > + pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node, > + "fsl,pcie-scfg"); > + if (IS_ERR(pcie->scfg)) { > + ret = PTR_ERR(pcie->scfg); > + dev_err(dev, "No syscfg phandle specified\n"); > + pcie->scfg = NULL; > + return ret; > + } > + > + ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg", > + index, 2); > + if (ret) { > + pcie->scfg = NULL; > + return ret; > + } > + > + pcie->index = index[1]; > + > + return 0; > +} Just an idea: what about using goto for error handling? (...) if (IS_ERR(pcie->scfg)) { ret = PTR_ERR(pcie->scfg); dev_err(dev, "No syscfg phandle specified\n"); goto error; } ret = of_property_read_u32_array(dev->of_node, "fsl,pcie-scfg", index, 2); if (ret) goto error; pcie->index = index[1]; return 0; error: pcie->scfg = NULL; return ret; } Not necessarily better or worse compared with your version, so it would be more of a matter of personal preference here. > +static int ls_pcie_suspend_noirq(struct device *dev) > +{ > + struct ls_pcie *pcie = dev_get_drvdata(dev); > + struct dw_pcie *pci = pcie->pci; > + u32 val; > + int ret; > + > + if (!ls_pcie_pm_check(pcie)) > + return 0; > + > + pcie->drvdata->pm_ops->send_turn_off_message(pcie); > + > + /* 10ms timeout to check L2 ready */ > + ret = readl_poll_timeout(pci->dbi_base + PCIE_PORT_DEBUG0, > + val, LS_PCIE_IS_L2(val), 100, 10000); > + if (ret) { > + dev_err(dev, "PCIe link enter L2 timeout! ltssm = 0x%x\n", val); > + return ret; > + } The error message above could be improve to be more like an error stating that something failed and such, as currently it looks like a debug message, unless it was intended as such. [...] > +static int ls_pcie_resume_noirq(struct device *dev) > +{ > + struct ls_pcie *pcie = dev_get_drvdata(dev); > + struct dw_pcie *pci = pcie->pci; > + int ret; > + > + if (!ls_pcie_pm_check(pcie)) > + return 0; > + > + ls_pcie_set_dstate(pcie, 0x0); > + > + pcie->drvdata->pm_ops->exit_from_l2(pcie); > + > + dw_pcie_setup_rc(&pci->pp); > + > + /* delay 10 ms to access EP */ > + mdelay(10); > + > + ret = ls_pcie_host_init(&pci->pp); > + if (ret) { > + dev_err(dev, "ls_pcie_host_init failed! ret = 0x%x\n", ret); > + return ret; > + } A small nitpick: error messages that are directed at end users should have a little more context than just the function name. Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel