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 X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 56BEBC04AB4 for ; Thu, 16 May 2019 09:40:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B13B2087E for ; Thu, 16 May 2019 09:40:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=mm-sol.com header.i=@mm-sol.com header.b="nK/xIje4" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbfEPJjv (ORCPT ); Thu, 16 May 2019 05:39:51 -0400 Received: from ns.mm-sol.com ([37.157.136.199]:48688 "EHLO extserv.mm-sol.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726374AbfEPJjv (ORCPT ); Thu, 16 May 2019 05:39:51 -0400 Received: from [192.168.27.209] (unknown [37.157.136.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by extserv.mm-sol.com (Postfix) with ESMTPSA id C8124CE6F; Thu, 16 May 2019 12:39:47 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mm-sol.com; s=201706; t=1557999587; bh=gtvWMbdQdnb7LYo5ABxwlV32TZDaPlVrBBH+/CofRko=; h=Subject:To:Cc:From:Date:From; b=nK/xIje4UFqTVVEISNtWB6QEO5a8wygY1e2E8Z4m7AUNg13m0ReU4WT9GSKz4Hytj zmXkUJqsSxM4oCkQYsAD00OVwDTXFWH1h3g7n2pC1OgEKo8v6jPdb/sSIYAQ5omiQD DrBhURBmTklidAqq1Mhdq+KizFSJAxNxMfL8f22EizKJVZkFrCBosYnwSoqei7y672 k4awo6qwCX7nelgUnfWv4ofToldsoX3K5gay5ZTE/WYH7/axgbMew41U52ZEDur+XH dY1BpCOTsNrkFEASqqp+k1nR0cOtnJhaQEY0WISnPCerI2SnrUET/KOTbkVpvh8DRV vwMfCR2A24YQw== Subject: Re: [PATCH v3 3/3] PCI: qcom: Add QCS404 PCIe controller support To: Bjorn Andersson , Bjorn Helgaas , Lorenzo Pieralisi Cc: Rob Herring , Mark Rutland , linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20190502001955.10575-1-bjorn.andersson@linaro.org> <20190502001955.10575-4-bjorn.andersson@linaro.org> From: Stanimir Varbanov Message-ID: Date: Thu, 16 May 2019 12:39:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190502001955.10575-4-bjorn.andersson@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Bjorn, On 5/2/19 3:19 AM, Bjorn Andersson wrote: > The QCS404 platform contains a PCIe controller of version 2.4.0 and a > Qualcomm PCIe2 PHY. The driver already supports version 2.4.0, for the > IPQ4019, but this support touches clocks and resets related to the PHY > as well, and there's no upstream driver for the PHY. > > On QCS404 we must initialize the PHY, so a separate PHY driver is > implemented to take care of this and the controller driver is updated to > not require the PHY related resources. This is done by relying on the > fact that operations in both the clock and reset framework are nops when > passed NULL, so we can isolate this change to only the get_resource > function. > > For QCS404 we also need to enable the AHB (iface) clock, in order to > access the register space of the controller, but as this is not part of > the IPQ4019 DT binding this is only added for new users of the 2.4.0 > controller. > > Reviewed-by: Niklas Cassel > Signed-off-by: Bjorn Andersson > --- > > Changes since v2: > - None > > drivers/pci/controller/dwc/pcie-qcom.c | 64 +++++++++++++++----------- > 1 file changed, 38 insertions(+), 26 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index d740cbe0e56d..d101bc5c0def 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -112,7 +112,7 @@ struct qcom_pcie_resources_2_3_2 { > struct regulator_bulk_data supplies[QCOM_PCIE_2_3_2_MAX_SUPPLY]; > }; > > -#define QCOM_PCIE_2_4_0_MAX_CLOCKS 3 > +#define QCOM_PCIE_2_4_0_MAX_CLOCKS 4 > struct qcom_pcie_resources_2_4_0 { > struct clk_bulk_data clks[QCOM_PCIE_2_4_0_MAX_CLOCKS]; > int num_clks; > @@ -638,13 +638,16 @@ static int qcom_pcie_get_resources_2_4_0(struct qcom_pcie *pcie) > struct qcom_pcie_resources_2_4_0 *res = &pcie->res.v2_4_0; > struct dw_pcie *pci = pcie->pci; > struct device *dev = pci->dev; > + bool is_ipq = of_device_is_compatible(dev->of_node, "qcom,pcie-ipq4019"); > int ret; > > res->clks[0].id = "aux"; > res->clks[1].id = "master_bus"; > res->clks[2].id = "slave_bus"; > + res->clks[3].id = "iface"; > > - res->num_clks = 3; > + /* qcom,pcie-ipq4019 is defined without "iface" */ > + res->num_clks = is_ipq ? 3 : 4; This is ugly but I don't have better idea except having static const resource structures where we can describe num_clks and select the right resource from compatible string, but lets leave that for the future. Otherwise: Acked-by: Stanimir Varbanov -- regards, Stan