Received: by 10.213.65.68 with SMTP id h4csp321388imn; Fri, 6 Apr 2018 00:18:47 -0700 (PDT) X-Google-Smtp-Source: AIpwx48ZwigogRcUZpDQSyRDlaccHeLO/1Ok0Me5scYVdeopj6eY0T/RJnhSjjfuzdYzFbb7TKJX X-Received: by 10.99.169.1 with SMTP id u1mr17422132pge.251.1522999127720; Fri, 06 Apr 2018 00:18:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522999127; cv=none; d=google.com; s=arc-20160816; b=Q68vinfxY1z9wfaMWEnD2wm09+jhYwIxANRGs5ui63FqIMJn+/l5yCIWRyfrkXd8qG rzanF5H27a5I8YgE+sxm0A6m5j2nVNxwGQeAJO2Hu0PlDeqsZ70f0Ift+486gAFDQUqq pq8lK2qfOlqAVAAqBC/yvlu3Nb5jd/csy3Aga08xJlC6LCzQVjgR4ifiov1sJkxu0xXs s5T1qm/Sob57negvlHqwXIFYVLMu6w68/M1O486zExqZUhJ5FxBhPDkFn97B8OPnAYyZ dhClABsek4ikUSkdxIm7XzQGftNp5fNdf9dEiPIk5dXOT7Scec9Q8YdcVYn7wAQqQbGa gMsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:dkim-signature:arc-authentication-results; bh=HkDg/sFl9zk4K9oeaO1h5nvGdyppV5UDGtZelBzYRXw=; b=eMHAXSizde5oD72UR4vzxIokAbVhjoQ76bq3jU+dIUojq5pK6Ha6lEyMFvnSlQ7PSS gud4aBRJsiWk2dzz5SwRDWeVMtUt8ys94L+4+i3lWjxHZruSnueHgZ+tgHUWQF479bTz pjL4fcDxv4AWJNcT6z+slXiF9p2yZipmSK8YZiFD+QlUWtQzWUSZIMX6QgXswMZT+37n uUNpHEC9d1otg9cUEMDc6bo5n5XmAz2dDysTNHNcg7DKiXDgKmPUF3zsb0dNxCU+mp+Z pKaB8cVh9fnWx4kFXtSwIP45EO68/VgtUjFw1OGw4gFUKfaf+UNpcuJguFTQA/hxlQoq r1kg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=lxVznCfW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l84si7615115pfj.344.2018.04.06.00.18.33; Fri, 06 Apr 2018 00:18:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=lxVznCfW; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751849AbeDFHRK (ORCPT + 99 others); Fri, 6 Apr 2018 03:17:10 -0400 Received: from lelnx194.ext.ti.com ([198.47.27.80]:13056 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751276AbeDFHRH (ORCPT ); Fri, 6 Apr 2018 03:17:07 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id w367H16V012834; Fri, 6 Apr 2018 02:17:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1522999021; bh=AvzknrWU4+qmx7r4NKbw9rpIC+JofFKUEkl0Tu4gKwY=; h=Subject:To:References:CC:From:Date:In-Reply-To; b=lxVznCfWHKuUNuouGPdFXnmaVYtH4xBG05nzfnRLBZPqrWwAu3hOwUWDRO0scpqqB 0uErIZX1zkM2dl+iu/24uTFytpKmALORQirT3cwHbZNWZrf021dSe7/TUvWmaCYfGc m1mbgc9QSDolke5Y9FgFNE2TCD7fsfDeVGVPLNR0= Received: from DFLE103.ent.ti.com (dfle103.ent.ti.com [10.64.6.24]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w367H0bM011960; Fri, 6 Apr 2018 02:17:00 -0500 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE103.ent.ti.com (10.64.6.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 6 Apr 2018 02:17:00 -0500 Received: from dflp32.itg.ti.com (10.64.6.15) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Fri, 6 Apr 2018 02:17:00 -0500 Received: from [172.24.190.233] (ileax41-snat.itg.ti.com [10.172.224.153]) by dflp32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w367Gvn9025872; Fri, 6 Apr 2018 02:16:57 -0500 Subject: Re: [PATCH 2/8] PCI: dwc: designware: Add support for endpoint mode To: Gustavo Pimentel , "bhelgaas@google.com" , "lorenzo.pieralisi@arm.com" , "Joao.Pinto@synopsys.com" , "jingoohan1@gmail.com" , "robh+dt@kernel.org" , "mark.rutland@arm.com" References: <93aafb03af86885994e633da240ef58dbd3f4d53.1522235224.git.gustavo.pimentel@synopsys.com> <339b02fa-47bb-bd36-a1b2-72ff315c3f7a@synopsys.com> CC: "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" From: Kishon Vijay Abraham I Message-ID: Date: Fri, 6 Apr 2018 12:46:56 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <339b02fa-47bb-bd36-a1b2-72ff315c3f7a@synopsys.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Wednesday 04 April 2018 03:50 PM, Gustavo Pimentel wrote: > On 02/04/2018 06:34, Kishon Vijay Abraham I wrote: >> Hi, >> >> On Wednesday 28 March 2018 05:08 PM, Gustavo Pimentel wrote: >>> The PCIe controller dual mode is capable of operating in host mode as well >>> as endpoint mode by configuration, therefore this patch aims to add >>> endpoint mode support to the designware driver. >>> >>> Signed-off-by: Gustavo Pimentel >>> --- >>> drivers/pci/dwc/Kconfig | 45 ++++++-- >>> drivers/pci/dwc/pcie-designware-plat.c | 157 ++++++++++++++++++++++++-- >>> drivers/pci/endpoint/functions/pci-epf-test.c | 5 + >>> 3 files changed, 187 insertions(+), 20 deletions(-) >>> >>> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig >>> index 2f3f5c5..3fd7daf 100644 >>> --- a/drivers/pci/dwc/Kconfig >>> +++ b/drivers/pci/dwc/Kconfig >>> @@ -7,8 +7,7 @@ config PCIE_DW >>> >>> config PCIE_DW_HOST >>> bool >>> - depends on PCI >>> - depends on PCI_MSI_IRQ_DOMAIN >>> + depends on PCI && PCI_MSI_IRQ_DOMAIN >>> select PCIE_DW >>> >>> config PCIE_DW_EP >>> @@ -52,16 +51,42 @@ config PCI_DRA7XX_EP >>> >>> config PCIE_DW_PLAT >>> bool "Platform bus based DesignWare PCIe Controller" >>> - depends on PCI >>> - depends on PCI_MSI_IRQ_DOMAIN >>> - select PCIE_DW_HOST >>> - ---help--- >>> - This selects the DesignWare PCIe controller support. Select this if >>> - you have a PCIe controller on Platform bus. >>> + help >>> + There are two instances of PCIe controller in Designware IP. >>> + This controller can work either as EP or RC. In order to enable >>> + host-specific features PCIE_DW_PLAT_HOST must be selected and in >>> + order to enable device-specific features PCIE_DW_PLAT_EP must be >>> + selected. >>> >>> - If you have a controller with this interface, say Y or M here. >>> +config PCIE_DW_PLAT_HOST >>> + bool "Platform bus based DesignWare PCIe Controller - Host mode" >>> + depends on PCI && PCI_MSI_IRQ_DOMAIN >>> + select PCIE_DW_HOST >>> + select PCIE_DW_PLAT >>> + default y >>> + help >>> + Enables support for the PCIe controller in the Designware IP to >>> + work in host mode. There are two instances of PCIe controller in >>> + Designware IP. >>> + This controller can work either as EP or RC. In order to enable >>> + host-specific features PCIE_DW_PLAT_HOST must be selected and in >>> + order to enable device-specific features PCI_DW_PLAT_EP must be >>> + selected. >>> >>> - If unsure, say N. >>> +config PCIE_DW_PLAT_EP >>> + bool "Platform bus based DesignWare PCIe Controller - Endpoint mode" >>> + depends on PCI && PCI_MSI_IRQ_DOMAIN >>> + depends on PCI_ENDPOINT >>> + select PCIE_DW_EP >>> + select PCIE_DW_PLAT >>> + help >>> + Enables support for the PCIe controller in the Designware IP to >>> + work in endpoint mode. There are two instances of PCIe controller >>> + in Designware IP. >>> + This controller can work either as EP or RC. In order to enable >>> + host-specific features PCIE_DW_PLAT_HOST must be selected and in >>> + order to enable device-specific features PCI_DW_PLAT_EP must be >>> + selected. >>> >>> config PCI_EXYNOS >>> bool "Samsung Exynos PCIe controller" >>> diff --git a/drivers/pci/dwc/pcie-designware-plat.c b/drivers/pci/dwc/pcie-designware-plat.c >>> index 5416aa8..921ab07 100644 >>> --- a/drivers/pci/dwc/pcie-designware-plat.c >>> +++ b/drivers/pci/dwc/pcie-designware-plat.c >>> @@ -12,19 +12,29 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> #include >>> #include >>> #include >>> +#include >>> >>> #include "pcie-designware.h" >>> >>> struct dw_plat_pcie { >>> - struct dw_pcie *pci; >>> + struct dw_pcie *pci; >>> + struct regmap *regmap; >>> + enum dw_pcie_device_mode mode; >>> }; >>> >>> +struct dw_plat_pcie_of_data { >>> + enum dw_pcie_device_mode mode; >>> +}; >>> + >>> +static const struct of_device_id dw_plat_pcie_of_match[]; >>> + >>> static int dw_plat_pcie_host_init(struct pcie_port *pp) >>> { >>> struct dw_pcie *pci = to_dw_pcie_from_pp(pp); >>> @@ -42,9 +52,61 @@ static const struct dw_pcie_host_ops dw_plat_pcie_host_ops = { >>> .host_init = dw_plat_pcie_host_init, >>> }; >>> >>> -static int dw_plat_add_pcie_port(struct pcie_port *pp, >>> +static int dw_plat_pcie_establish_link(struct dw_pcie *pci) >>> +{ >>> + dw_pcie_ep_linkup(&pci->ep); >> >> .start_link ops is used incorrectly here. .start_link is used when all the >> endpoint side configuration is done and "is ready" to establish a link with the >> host. But dw_pcie_ep_linkup is used to inform the function devices that the >> link "has been" established. > > If I move the dw_pcie_ep_linkup call from the dw_plat_pcie_establish_link to the > dw_plat_pcie_ep_init function it would be more correct in your perspective? If > not, where you suggest? No, dw_pcie_ep_linkup is an optional function. If your platform gives a notification when the link to the host is established, then you have to invoke this function. If you keep "linkup_notifier = false" in pci-epf-test.c, dw_pcie_ep_linkup should be required. > >>> + >>> + return 0; >>> +} >>> + >>> +static void dw_plat_pcie_stop_link(struct dw_pcie *pci) >>> +{ >>> + >>> +} >> >> Not necessary to have empty function here. pci-epc-core will not try to invoke >> ops which are not populated. > > Ok, I'll remove it. > >>> + >>> +static const struct dw_pcie_ops dw_pcie_ops = { >>> + .start_link = dw_plat_pcie_establish_link, >>> + .stop_link = dw_plat_pcie_stop_link, >>> +}; >>> + >>> +static void dw_plat_pcie_ep_init(struct dw_pcie_ep *ep) >>> +{ >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep); >>> + enum pci_barno bar; >>> + >>> + for (bar = BAR_0; bar <= BAR_5; bar++) >>> + dw_pcie_ep_reset_bar(pci, bar); >>> +} >>> + >>> +static int dw_plat_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no, >>> + enum pci_epc_irq_type type, >>> + u8 interrupt_num) >>> +{ >>> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep); >>> + >>> + switch (type) { >>> + case PCI_EPC_IRQ_LEGACY: >>> + dev_err(pci->dev, "EP cannot trigger legacy IRQs\n"); >>> + return -EINVAL; >>> + case PCI_EPC_IRQ_MSI: >>> + return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num); >>> + default: >>> + dev_err(pci->dev, "UNKNOWN IRQ type\n"); >>> + } >>> + >>> + return 0; >>> +} >>> + >>> +static struct dw_pcie_ep_ops pcie_ep_ops = { >>> + .ep_init = dw_plat_pcie_ep_init, >>> + .raise_irq = dw_plat_pcie_ep_raise_irq, >>> +}; >>> + >>> +static int dw_plat_add_pcie_port(struct dw_plat_pcie *dw_plat_pcie, >>> struct platform_device *pdev) >>> { >>> + struct dw_pcie *pci = dw_plat_pcie->pci; >>> + struct pcie_port *pp = &pci->pp; >>> struct device *dev = &pdev->dev; >>> int ret; >>> >>> @@ -63,15 +125,44 @@ static int dw_plat_add_pcie_port(struct pcie_port *pp, >>> >>> ret = dw_pcie_host_init(pp); >>> if (ret) { >>> - dev_err(dev, "failed to initialize host\n"); >>> + dev_err(dev, "Failed to initialize host\n"); >>> return ret; >>> } >>> >>> return 0; >>> } >>> >>> -static const struct dw_pcie_ops dw_pcie_ops = { >>> -}; >>> +static int dw_plat_add_pcie_ep(struct dw_plat_pcie *dw_plat_pcie, >>> + struct platform_device *pdev) >>> +{ >>> + int ret; >>> + struct dw_pcie_ep *ep; >>> + struct resource *res; >>> + struct device *dev = &pdev->dev; >>> + struct dw_pcie *pci = dw_plat_pcie->pci; >>> + >>> + ep = &pci->ep; >>> + ep->ops = &pcie_ep_ops; >>> + >>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi2"); >>> + pci->dbi_base2 = devm_ioremap(dev, res->start, resource_size(res)); >>> + if (IS_ERR(pci->dbi_base2)) >>> + return PTR_ERR(pci->dbi_base2); >>> + >>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "addr_space"); >>> + if (!res) >>> + return -EINVAL; >>> + >>> + ep->phys_base = res->start; >>> + ep->addr_size = resource_size(res); >>> + >>> + ret = dw_pcie_ep_init(ep); >>> + if (ret) { >>> + dev_err(dev, "Failed to initialize endpoint\n"); >>> + return ret; >>> + } >>> + return 0; >>> +} >>> >>> static int dw_plat_pcie_probe(struct platform_device *pdev) >>> { >>> @@ -80,6 +171,16 @@ static int dw_plat_pcie_probe(struct platform_device *pdev) >>> struct dw_pcie *pci; >>> struct resource *res; /* Resource from DT */ >>> int ret; >>> + const struct of_device_id *match; >>> + const struct dw_plat_pcie_of_data *data; >>> + enum dw_pcie_device_mode mode; >>> + >>> + match = of_match_device(dw_plat_pcie_of_match, dev); >>> + if (!match) >>> + return -EINVAL; >>> + >>> + data = (struct dw_plat_pcie_of_data *)match->data; >>> + mode = (enum dw_pcie_device_mode)data->mode; >>> >>> dw_plat_pcie = devm_kzalloc(dev, sizeof(*dw_plat_pcie), GFP_KERNEL); >>> if (!dw_plat_pcie) >>> @@ -93,23 +194,59 @@ static int dw_plat_pcie_probe(struct platform_device *pdev) >>> pci->ops = &dw_pcie_ops; >>> >>> dw_plat_pcie->pci = pci; >>> + dw_plat_pcie->mode = mode; >>> + >>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dbi"); >>> + if (!res) >>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> >>> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> pci->dbi_base = devm_ioremap_resource(dev, res); >>> if (IS_ERR(pci->dbi_base)) >>> return PTR_ERR(pci->dbi_base); >>> >>> platform_set_drvdata(pdev, dw_plat_pcie); >>> >>> - ret = dw_plat_add_pcie_port(&pci->pp, pdev); >>> - if (ret < 0) >>> - return ret; >>> + switch (dw_plat_pcie->mode) { >>> + case DW_PCIE_RC_TYPE: >>> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_HOST)) >>> + return -ENODEV; >>> + >>> + ret = dw_plat_add_pcie_port(dw_plat_pcie, pdev); >>> + if (ret < 0) >>> + return ret; >>> + break; >>> + case DW_PCIE_EP_TYPE: >>> + if (!IS_ENABLED(CONFIG_PCIE_DW_PLAT_EP)) >>> + return -ENODEV; >>> + >>> + ret = dw_plat_add_pcie_ep(dw_plat_pcie, pdev); >>> + if (ret < 0) >>> + return ret; >>> + break; >>> + default: >>> + dev_err(dev, "INVALID device type %d\n", dw_plat_pcie->mode); >>> + } >>> >>> return 0; >>> } >>> >>> +static const struct dw_plat_pcie_of_data dw_plat_pcie_rc_of_data = { >>> + .mode = DW_PCIE_RC_TYPE, >>> +}; >>> + >>> +static const struct dw_plat_pcie_of_data dw_plat_pcie_ep_of_data = { >>> + .mode = DW_PCIE_EP_TYPE, >>> +}; >>> + >>> static const struct of_device_id dw_plat_pcie_of_match[] = { >>> - { .compatible = "snps,dw-pcie", }, >>> + { >>> + .compatible = "snps,dw-pcie", >>> + .data = &dw_plat_pcie_rc_of_data, >>> + }, >>> + { >>> + .compatible = "snps,dw-pcie-ep", >>> + .data = &dw_plat_pcie_ep_of_data, >>> + }, >>> {}, >>> }; >>> >>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c >>> index 64d8a17..d7de684 100644 >>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c >>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c >>> @@ -451,9 +451,14 @@ static int pci_epf_test_bind(struct pci_epf *epf) >>> return 0; >>> } >>> >>> +static const struct pci_epf_test_data pci_epf_data = { >>> + .linkup_notifier = false >>> +}; >>> + >>> static const struct pci_epf_device_id pci_epf_test_ids[] = { >>> { >>> .name = "pci_epf_test", >>> + .driver_data = (kernel_ulong_t)&pci_epf_data, >> >> This will disable linkup_notifier for existing devices. Please add a new entry >> to the table to make any modifications to driver data. (I have a configfs fix >> for this to work. Will post that today). > > Are you refering to this patch? https://patchwork.kernel.org/patch/10319695/ > Let's see if I understood it right, this patch will expose the some configfs > (something like /sys/kernel/config/pci_ep/functions/pci_epf_test/func1/...) that > ables me to disable the linkup notifier for existing devices without the need to > change the code like I did, right? Actually that patch doesn't add any configfs attribute entry. It just creates a new configfs directory for every entry populated in pci_epf_device_id. For example, If you have something like this static const struct pci_epf_test_data k2g_data = { .test_reg_bar = BAR_1, .linkup_notifier = false }; static const struct pci_epf_device_id pci_epf_test_ids[] = { { .name = "pci_epf_test", }, { .name = "pci_epf_test_k2g", .driver_data = (kernel_ulong_t)&k2g_data, }, {}, }; after [1], there should be 2 entries in /sys/kernel/config/pci_ep/functions/ pci_epf_test and pci_epf_test_k2g. Here if you use pci_epf_test_k2g entry then the driver data associated with pci_epf_test_k2g will be used. Thanks Kishon [1] -> https://patchwork.kernel.org/patch/10319695/ > >> >> Thanks >> Kishon >> > >