Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4449140pxv; Tue, 29 Jun 2021 07:18:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywOw+abL2+LvNQiytvJduSo7gvOPfoXXhHEmCzLBCWJNfRZVx1AS+JBKRp6ACLAGrlZcpR X-Received: by 2002:a05:6402:214:: with SMTP id t20mr41425855edv.20.1624976299591; Tue, 29 Jun 2021 07:18:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624976299; cv=none; d=google.com; s=arc-20160816; b=m3365mc6QPdVfGUJKUuiEekG0LWF7IS9LJYvhMww48VorVl8nzYBtEoXhsPx6fBMJZ U42pZ079l9Xr51TXN2BPqRtC7kYvuOCvdqjmDIgzGRotCVgh9p99TTXNvQI2q+r7+ggc CHOZFM5wnMy5KFfBGB+EgnAbPzvoq8TU06ft46K7YsQlkDlK4R37XkOqNXR/FhZwhwRm 1alpZ7/Ajo9EtG9QRDkJ0Tx5RIvzPiVJ1NvO6od9PQbatNebx70/kUjgx/Apu5W2vynh HC5Mk27M68v4KeDKvSQ5KEFp7CB2sTXBn56+V2tN3clDcDkGmSiYrEW2l0j5juT/9Blb uBHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=f3OA1dbE+qUdV5an6bSR6AZUtN3k+/RtXxo9mlqVUD4=; b=0TS1+zcsJunyV61flpGqwCIO/pXPgaUvi0LaZ3hmKOnSG/cn4HrgB5FVTW7whaGNGt bH79rGVTme+VXtZXfUhtBoPSsGPXKJLNcTWVFXVnf2w8XhAFBDghh+mxQlVoS75eZmHM GMu9xbZ6GbecTSUTetGOtb5buwJzJDY1KTjl8vMGY1Bm7WR3YQungvBiXRT8XMNvnQvF OR6kMThCX3sfIQKslTPDOWqh6sl5BI3Mm3I+rrKkpmoN+MPLFXH2Rx3QQ7GmGh50Nb8u N3jgb5E5nD/zng5tek2k1KysWmcR0Kq4liXMwypw35Fk4bc65g56oKa0kOHd9ncH3QQg 7iLw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=giSyB9WU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gv8si3041065ejc.710.2021.06.29.07.17.55; Tue, 29 Jun 2021 07:18:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=giSyB9WU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234313AbhF2OTS (ORCPT + 99 others); Tue, 29 Jun 2021 10:19:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43080 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234339AbhF2OTQ (ORCPT ); Tue, 29 Jun 2021 10:19:16 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 95F91C061760 for ; Tue, 29 Jun 2021 07:16:47 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id d12so9597444pfj.2 for ; Tue, 29 Jun 2021 07:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=f3OA1dbE+qUdV5an6bSR6AZUtN3k+/RtXxo9mlqVUD4=; b=giSyB9WUShwPd56VuIVkAfkBt51oAFRupZIVXyDbxohZNrT6uX/PGzO4YfcR6RXy2k zOoE9FnqYNNNW96vvxr1bPmxraitY/YRdE38PjpLqermFLgjcezEOfBQhnrhgGLPsm+f CQG1vwUpbeKG+RHT8FV7BQlX0VwMwVqiL+5I81G9bPoTOls0yp8tQBH/5g/2qknzQ9LP M0W0367iZ77m2J9ZALvSFTI9B3aW/fKx33tP08PU/jatdYErjUNbeb3BGZjQpYU7WeG6 DZQbSIKryKZxXEKIk9HNZHVuX9QGC8N27FcFfBdaUyQzYZ5a4wmdfSssZuKrRBer787O bQ/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=f3OA1dbE+qUdV5an6bSR6AZUtN3k+/RtXxo9mlqVUD4=; b=gZA9gBgiWjeMIEHhMgVDLukWg969pZIK7HODOn++gqvwXCkFQPylXuPmXSWhEnKlrG WERAH1fXKVXf2xvixxGI1F4Rc5Mi1cnFkwh9T1eaOphH/6ittAmQf1u88LcQgOrbDpHg hFR0mh7DcPMOzWk6D+bkZEd/+7Jz+O7n/ktb9G2Gm+0wgi4/l+QXd4LJE3y91F0pD98L NFoLuUuUcVcUQj3sX7RSiwnkFhc6ELNVgsAN0JkmG8HwBPNogPiMvvg8li5JBEpqyteB XqlbkOVWdVQHmqRJEN7obvMXqdhsF6GZH+NFn1E9IY/m92cFkeHeVOXCa/46xqzyVctW xyew== X-Gm-Message-State: AOAM533z/qD+k9eOuDu+muSme04tdBieHV1w9QgCzyX391hLzAdDDg+P FJ3cX/qUucutg+qr70xbp1kS X-Received: by 2002:a63:500f:: with SMTP id e15mr11092658pgb.391.1624976207008; Tue, 29 Jun 2021 07:16:47 -0700 (PDT) Received: from workstation ([120.138.12.32]) by smtp.gmail.com with ESMTPSA id m2sm3676672pja.9.2021.06.29.07.16.42 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 29 Jun 2021 07:16:46 -0700 (PDT) Date: Tue, 29 Jun 2021 19:46:41 +0530 From: Manivannan Sadhasivam To: Rob Herring Cc: Kishon Vijay Abraham I , Lorenzo Pieralisi , Bjorn Helgaas , devicetree@vger.kernel.org, PCI , "linux-kernel@vger.kernel.org" , linux-arm-msm , hemantk@codeaurora.org, Siddartha Mohanadoss , Bjorn Andersson , Sriharsha Allenki , skananth@codeaurora.org, vpernami@codeaurora.org, Veerabhadrarao Badiganti Subject: Re: [PATCH v4 2/3] PCI: dwc: Add Qualcomm PCIe Endpoint controller driver Message-ID: <20210629141641.GB3580@workstation> References: <20210624072534.21191-1-manivannan.sadhasivam@linaro.org> <20210624072534.21191-3-manivannan.sadhasivam@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 24, 2021 at 08:39:31AM -0600, Rob Herring wrote: > (). On Thu, Jun 24, 2021 at 1:26 AM Manivannan Sadhasivam > wrote: > > > > Add driver support for Qualcomm PCIe Endpoint controller driver based on > > the Designware core with added Qualcomm specific wrapper around the > > core. The driver support is very basic such that it supports only > > enumeration, PCIe read/write, and MSI. There is no ASPM and PM support > > for now but these will be added later. > > > > The driver is capable of using the PERST# and WAKE# side-band GPIOs for > > operation and written on top of the DWC PCI framework. > > > > Co-developed-by: Siddartha Mohanadoss > > Signed-off-by: Siddartha Mohanadoss > > [mani: restructured the driver and fixed several bugs for upstream] > > Signed-off-by: Manivannan Sadhasivam > > --- > > drivers/pci/controller/dwc/Kconfig | 10 + > > drivers/pci/controller/dwc/Makefile | 1 + > > drivers/pci/controller/dwc/pcie-qcom-ep.c | 751 ++++++++++++++++++++++ > > 3 files changed, 762 insertions(+) > > create mode 100644 drivers/pci/controller/dwc/pcie-qcom-ep.c > > [...] > A bunch of these defines are already in pcie-qcom.c. Make a header for > the registers and common bits. > The registers are shared but the offsets differ. By comparing, there are just 3 registers that share the same offset. So I don't think it gives any benefit in introducing a common header. > > + > > +/* ELBI registers */ > > +#define ELBI_SYS_STTS 0x08 > > + > > +/* DBI registers */ > > +#define DBI_CAP_ID_NXT_PTR 0x40 > > +#define DBI_CON_STATUS 0x44 > > +#define DBI_DEVICE_CAPABILITIES 0x74 > > +#define DBI_LINK_CAPABILITIES 0x7c > > +#define DBI_LINK_CONTROL2_LINK_STATUS2 0xa0 > > +#define DBI_L1SUB_CAPABILITY 0x234 > > These are all standard PCIe config space registers. Use standard > defines and the offsets are discoverable. > Okay. > > +#define DBI_ACK_F_ASPM_CTRL 0x70c > > +#define DBI_GEN3_RELATED_OFF 0x890 > > +#define DBI_AUX_CLK_FREQ 0xb40 > > + > > +#define DBI_L0S_ACCPT_LATENCY_MASK GENMASK(8, 6) > > +#define DBI_L1_ACCPT_LATENCY_MASK GENMASK(11, 9) > > +#define DBI_L0S_EXIT_LATENCY_MASK GENMASK(14, 12) > > +#define DBI_L1_EXIT_LATENCY_MASK GENMASK(17, 15) > > +#define DBI_ACK_N_FTS_MASK GENMASK(15, 8) > > Standard DWC DBI registers. Use defines in pcie-designware.h and > really any code touching these registers belongs in the common DWC > code. > Looked into this part and found that most of the DBI settings can be skipped as the reset state is same. In v5, there will be only DBI_CON_STATUS register in this driver for reading the D-state in IRQ handler. I can't find any info about this register in the PCI spec. And by judging from its location (between PM capability register and MSI capability register), this seems to be Qcom specific. > > + > > +#define XMLH_LINK_UP 0x400 > > +#define CORE_RESET_TIME_US_MIN 1000 > > +#define CORE_RESET_TIME_US_MAX 1005 > > +#define WAKE_DELAY_US 2000 /* 2 ms */ > > + > > +#define to_pcie_ep(x) dev_get_drvdata((x)->dev) > > + > > +enum qcom_pcie_ep_link_status { > > + QCOM_PCIE_EP_LINK_DISABLED, > > + QCOM_PCIE_EP_LINK_ENABLED, > > + QCOM_PCIE_EP_LINK_UP, > > + QCOM_PCIE_EP_LINK_DOWN, > > +}; > > + > > +enum qcom_pcie_ep_irq { > > + QCOM_PCIE_EP_INT_RESERVED, > > + QCOM_PCIE_EP_INT_LINK_DOWN, > > + QCOM_PCIE_EP_INT_BME, > > + QCOM_PCIE_EP_INT_PM_TURNOFF, > > + QCOM_PCIE_EP_INT_DEBUG, > > + QCOM_PCIE_EP_INT_LTR, > > + QCOM_PCIE_EP_INT_MHI_Q6, > > + QCOM_PCIE_EP_INT_MHI_A7, > > + QCOM_PCIE_EP_INT_DSTATE_CHANGE, > > + QCOM_PCIE_EP_INT_L1SUB_TIMEOUT, > > + QCOM_PCIE_EP_INT_MMIO_WRITE, > > + QCOM_PCIE_EP_INT_CFG_WRITE, > > + QCOM_PCIE_EP_INT_BRIDGE_FLUSH_N, > > + QCOM_PCIE_EP_INT_LINK_UP, > > + QCOM_PCIE_EP_INT_AER_LEGACY, > > + QCOM_PCIE_EP_INT_PLS_ERR, > > + QCOM_PCIE_EP_INT_PME_LEGACY, > > + QCOM_PCIE_EP_INT_PLS_PME, > > + QCOM_PCIE_EP_INT_MAX, > > +}; > > + > > +static struct clk_bulk_data qcom_pcie_ep_clks[] = { > > + { .id = "cfg" }, > > + { .id = "aux" }, > > + { .id = "bus_master" }, > > + { .id = "bus_slave" }, > > + { .id = "ref" }, > > + { .id = "sleep" }, > > + { .id = "slave_q2a" }, > > +}; > > + > > +struct qcom_pcie_ep { > > + struct dw_pcie pci; > > + > > + void __iomem *parf; > > + void __iomem *elbi; > > + void __iomem *mmio; > > + struct regmap *perst_map; > > + > > + struct reset_control *core_reset; > > + struct gpio_desc *reset; > > + struct gpio_desc *wake; > > + struct phy *phy; > > + > > + resource_size_t dbi_phys; > > + resource_size_t atu_phys; > > These 2 are never used. > oh, that's a left over. will remove. > > + resource_size_t mmio_phys; > > + u32 mmio_size; > > 'mmio' is a horrible name. It's all MMIO. Is this 'addr_space' used by > other EP drivers? > No, this is the BAR region used by the device. This region is called MMIO in the hardware as it relates to the MHI bus and has the registers for MHI. Calling this region by some other name will induce a confusion since the MHI spec has been referencing this region as MMIO. > Just save a pointer to the resource if you need these. Or retrieve the > resource in the one place you need it. > Okay > > + u32 perst_en; > > + u32 perst_sep_en; > > + > > + enum qcom_pcie_ep_link_status link_status; > > + int global_irq; > > + int perst_irq; > > +}; > > + > > +static void qcom_pcie_ep_enable_ltssm(struct qcom_pcie_ep *pcie_ep) > > +{ > > + u32 reg; > > + > > + reg = readl(pcie_ep->parf + PARF_LTSSM); > > + reg |= BIT(8); > > + writel(reg, pcie_ep->parf + PARF_LTSSM); > > +} > > Same function as qcom_pcie_2_3_2_ltssm_enable(). > this is the only function shared between RC and EP drivers... > > > + [...] > > + > > + /* L1ss is supported */ > > + val = dw_pcie_readl_dbi(pci, DBI_L1SUB_CAPABILITY); > > + val |= 0x1f; > > + dw_pcie_writel_dbi(pci, DBI_L1SUB_CAPABILITY, val); > > + > > + /* Enable Clock Power Management */ > > + val = dw_pcie_readl_dbi(pci, DBI_LINK_CAPABILITIES); > > + val |= BIT(18); > > + dw_pcie_writel_dbi(pci, DBI_LINK_CAPABILITIES, val); > > Lots of magic values that need defines. > Will add defines for all of them > > + > > + dw_pcie_dbi_ro_wr_dis(pci); > > + > > + /* Set FTS value to match the PHY setting */ > > + val = dw_pcie_readl_dbi(pci, DBI_ACK_F_ASPM_CTRL); > > + val |= FIELD_PREP(DBI_ACK_N_FTS_MASK, 0x80); > > + dw_pcie_writel_dbi(pci, DBI_ACK_F_ASPM_CTRL, val); > > + > > + writel(0, pcie_ep->parf + PARF_INT_ALL_MASK); > > + val = BIT(QCOM_PCIE_EP_INT_LINK_DOWN) | > > + BIT(QCOM_PCIE_EP_INT_BME) | > > + BIT(QCOM_PCIE_EP_INT_PM_TURNOFF) | > > + BIT(QCOM_PCIE_EP_INT_DSTATE_CHANGE) | > > + BIT(QCOM_PCIE_EP_INT_LINK_UP); > > Move BIT() into the defines. > This has been done because QCOM_PCIE_EP_INT_* are defined as enums and shared with the IRQ handler. But I'll change these to defines with BIT() macro and will use if() condition for matching the events in irq handler. > > + writel(val, pcie_ep->parf + PARF_INT_ALL_MASK); > > + > > + return 0; > > +} > > + [...] > > + > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu"); > > + pci->atu_base = devm_pci_remap_cfg_resource(dev, res); > > The DWC core does this for you. > Oh yeah. I added this for getting the atu_phys address that needs to be written to some PARF registers. But in v4 I removed that logic and forgot to remove this. > > + if (IS_ERR(pci->atu_base)) > > + return PTR_ERR(pci->atu_base); > > + pcie_ep->atu_phys = res->start; > > + [...] > > + pcie_ep->perst_irq = gpiod_to_irq(pcie_ep->reset); > > + irq_set_status_flags(pcie_ep->perst_irq, IRQ_NOAUTOEN); > > + ret = devm_request_threaded_irq(&pdev->dev, pcie_ep->perst_irq, NULL, > > + qcom_pcie_ep_perst_threaded_irq, > > + IRQF_TRIGGER_HIGH | IRQF_ONESHOT, > > IRQ_TRIGGER_* should come from the DT. > How? We can specify the triggers in "interrupts*" property but here the IRQ is obtained from the GPIO. So I'm not sure how to specify the trigger in DT. Thanks, Mani