Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2853986pxk; Mon, 28 Sep 2020 01:35:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQFWHAS/KRnvtG4SpGAvnjAcRWxALQPNwQ9xqbJvXDBiBOIcaweRHC8IeaajtaDt68ERNz X-Received: by 2002:a17:906:82d1:: with SMTP id a17mr566313ejy.385.1601282108045; Mon, 28 Sep 2020 01:35:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601282108; cv=none; d=google.com; s=arc-20160816; b=ymUfj4/qbcGS+ZCLpXRRzPn4wZhj0osTcKHW4Wi7DGKl2k97lgfkePHCaMeBEhUcMe I9bQx4qveCjrsrwXyFabRuC9OqNIpq2ozLLMhcy83EUD8VbaCC1XN+HXelPgnV2gFOHv 2lw/qVJsbR32xzZztNzbun8k4IFwKp/HniXEO1/qMJgOrDjvEP6qV2ftQ2AG5adsLQDk OgwLjXIOSYl029ku3K+8GTqvCKwzbpT8nAlIcppaB1Tddue85ypvdhGzmbEyUgyo80zQ FBSX0hyMRLNbdeMZmvUncjnAiJS/7EN7y1Dd3in9+fsR964xVsqP5MQpuJ+ixOArOwZW fVyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id; bh=+Qdz+feN9JSgTZLEofh49sMLjTUYiGy3xp8uvlZq3M8=; b=nxnIiBm6k3QoxqMlOQRUfaPT7xAGy9hI0DAJRoaF6LBiJy8jUFpUwcquD8ri/2AdAf ef0GuxEFZu8OpiXgozJ2HNHfTphNQ4HPcg/6dfUz2a8WXE0nMf4k45rlwnAqYzOR9OUS J7f46/k54U4o55XrLvbyBndJfyvRPoE3F+2dDOC790DAwszb9oKP6Vy8ftcErR/R/Fu4 zeCGaTA9NSBVOpRvwaW+DsYcepSAt+qyDBT2hENi+ij/FzmvDv0l362bxrP+1OeomUrg MonIZeb+iC39y+Pt4Amw/Kcy6UKYCa1DAtBXejhX7HLh/jUPen8t1fOesE6/9mtzE46v FUuA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y22si185305ejm.431.2020.09.28.01.34.44; Mon, 28 Sep 2020 01:35:08 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726600AbgI1Ic7 convert rfc822-to-8bit (ORCPT + 99 others); Mon, 28 Sep 2020 04:32:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726576AbgI1Ic7 (ORCPT ); Mon, 28 Sep 2020 04:32:59 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3D1A4C0613CF for ; Mon, 28 Sep 2020 01:32:59 -0700 (PDT) Received: from lupine.hi.pengutronix.de ([2001:67c:670:100:3ad5:47ff:feaf:1a17] helo=lupine) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kMoaY-00083X-Mf; Mon, 28 Sep 2020 10:32:50 +0200 Received: from pza by lupine with local (Exim 4.92) (envelope-from ) id 1kMoaQ-0004M0-Ts; Mon, 28 Sep 2020 10:32:42 +0200 Message-ID: Subject: Re: [v3,2/3] PCI: mediatek: Add new generation controller support From: Philipp Zabel To: Jianjun Wang , Bjorn Helgaas , Rob Herring , Lorenzo Pieralisi , Ryder Lee Cc: Matthias Brugger , Mauro Carvalho Chehab , davem@davemloft.net, linux-pci@vger.kernel.org, linux-mediatek@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Sj Huang , youlin.pei@mediatek.com, chuanjia.liu@mediatek.com, qizhong.cheng@mediatek.com, sin_jieyang@mediatek.com Date: Mon, 28 Sep 2020 10:32:42 +0200 In-Reply-To: <20200927074555.4155-3-jianjun.wang@mediatek.com> References: <20200927074555.4155-1-jianjun.wang@mediatek.com> <20200927074555.4155-3-jianjun.wang@mediatek.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2001:67c:670:100:3ad5:47ff:feaf:1a17 X-SA-Exim-Mail-From: p.zabel@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jianjun, On Sun, 2020-09-27 at 15:45 +0800, Jianjun Wang wrote: > MediaTek's PCIe host controller has three generation HWs, the new > generation HW is an individual bridge, it supoorts Gen3 speed and > up to 256 MSI interrupt numbers for multi-function devices. > > Add support for new Gen3 controller which can be found on MT8192. > > Signed-off-by: Jianjun Wang > Acked-by: Ryder Lee > --- > drivers/pci/controller/Kconfig | 14 + > drivers/pci/controller/Makefile | 1 + > drivers/pci/controller/pcie-mediatek-gen3.c | 1024 +++++++++++++++++++ > 3 files changed, 1039 insertions(+) > create mode 100644 drivers/pci/controller/pcie-mediatek-gen3.c > [...] > diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c > new file mode 100644 > index 000000000000..ad69c789b24d > --- /dev/null > +++ b/drivers/pci/controller/pcie-mediatek-gen3.c > @@ -0,0 +1,1024 @@ [...] > +static int mtk_pcie_power_up(struct mtk_pcie_port *port) > +{ > + struct device *dev = port->dev; > + int err; > + > + port->phy_reset = devm_reset_control_get_optional_exclusive(dev, > + "phy-rst"); > + if (IS_ERR(port->phy_reset)) > + return PTR_ERR(port->phy_reset); > + > + reset_control_deassert(port->phy_reset); In general, it is better to request all required resources before starting to activate the hardware. > + > + /* PHY power on and enable pipe clock */ > + port->phy = devm_phy_optional_get(dev, "pcie-phy"); > + if (IS_ERR(port->phy)) > + return PTR_ERR(port->phy); For example, if the PHY driver is not loaded yet and this returns -EPROBE_DEFER, it was not useful to take the PHY out of reset above. Also, phy-rst is kept deasserted if this fails. > + > + err = phy_init(port->phy); > + if (err) { > + dev_notice(dev, "failed to initialize pcie phy\n"); > + return err; phy-rst is kept deasserted if this fails. > + } > + > + err = phy_power_on(port->phy); > + if (err) { > + dev_notice(dev, "failed to power on pcie phy\n"); > + goto err_phy_on; > + } > + > + port->mac_reset = devm_reset_control_get_optional_exclusive(dev, > + "mac-rst"); > + if (IS_ERR(port->mac_reset)) > + return PTR_ERR(port->mac_reset); The PHY is not powered down if this fails. > + > + reset_control_deassert(port->mac_reset); > + > + /* MAC power on and enable transaction layer clocks */ > + pm_runtime_enable(dev); > + pm_runtime_get_sync(dev); > + > + err = mtk_pcie_clk_init(port); > + if (err) { > + dev_notice(dev, "clock init failed\n"); > + goto err_clk_init; > + } > + > + return 0; > + > +err_clk_init: > + pm_runtime_put_sync(dev); > + pm_runtime_disable(dev); > + reset_control_assert(port->mac_reset); > + phy_power_off(port->phy); > +err_phy_on: > + phy_exit(port->phy); > + reset_control_assert(port->phy_reset); > + > + return -EBUSY; > +} > + > +static void mtk_pcie_power_down(struct mtk_pcie_port *port) > +{ > + phy_power_off(port->phy); > + phy_exit(port->phy); > + > + clk_bulk_disable_unprepare(port->num_clks, port->clks); In the power-up sequence clocks are enabled last, but here they are not disabled before the PHY is powered off. Is this on purpose? > + > + pm_runtime_put_sync(port->dev); > + pm_runtime_disable(port->dev); In the power-up error path, PHY and controller resets are asserted again, but here they are kept deasserted. Should they be asserted here as well? regards Philipp