Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4601477pxb; Tue, 31 Aug 2021 08:54:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVNeIZ4waHl6wFwUWjeM7GxMtpVbKFkSGAJ/zJhCrITiFxsmnep6Ep8gw5sDzo4RIZFccI X-Received: by 2002:a17:906:374e:: with SMTP id e14mr30855304ejc.161.1630425262299; Tue, 31 Aug 2021 08:54:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630425262; cv=none; d=google.com; s=arc-20160816; b=cO3OCxCmMUNQOLPjFK77bGdJzE0gJUNbaqwHKZMGMjbdgOS+CWWOo8pTW2gJJFzuSx S4e/BcQoMnbi56hnkTi/RNKaBzZVwTEwDRVdjjDSDA7ialGlyTMj/u6Efgv/B9IUdLGb 8OIdPDgImqRjwcbr+vAkdTRNi6WNOMqf+sDmbPGhBcajN+h/xSdZ3lAhwdkOkmqpp5Zn Ji2xVB+wwOE5KFJ4lvVoesC+rI0II+e4T9u2pZWPiTD5w/L7mN5WKJEzDHUP1HywEqCl dzN7LhyHwNudDAnunGDKXG4JTJ5o5ymP4ReR+VsNGMagA+S1kplGlv7lMaq7uqA168WZ uGGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=ypBRm5omwxAi4KoAHgjWkvSvo0ycGC5Hd9sdY657+gE=; b=ZaJPc9bQR2tYMuTu7iIy6vcAH0I+LmEbP05zUOBz/OJpwfOb5hAul85lLTEc1FjWWF xeHWlyjlmoctCAI3QRfjG5iNGW+PHwhLX5ZOG1QlAWvYibdXpCBGWejOiwnYIxokJIH2 uUEDJvYdc776LnC6jtb/D2FIbOHmIvR99pzPs+SIUBL2YRKpXF0Gx1DasVaMY6wk/FXe 9C09NgjqgC90LbRy0FF29IW+G/+y+BQAca4LpL5JfcWcPwvUs97s3C3IHDByPTPvk3NA 7Adf7qCfEMyK82YCO9WECEYYe5K4BXBrlw+K5zFg71emeDvlQztM2k7DNz1IG6HlolBF hwMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=iO4JPZHO; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i17si17146015edq.189.2021.08.31.08.53.58; Tue, 31 Aug 2021 08:54:22 -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=@kernel.org header.s=k20201202 header.b=iO4JPZHO; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239625AbhHaPsI (ORCPT + 99 others); Tue, 31 Aug 2021 11:48:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:59936 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239594AbhHaPsH (ORCPT ); Tue, 31 Aug 2021 11:48:07 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 343DB60F46; Tue, 31 Aug 2021 15:47:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630424832; bh=TnQQpCYETDT/ylSVf5eWQ2bbH/+ot85D9Zd3GWer9E0=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=iO4JPZHO/sCO/8Sw7XAgTAKl6Csj4B6jxZbxrbh898E3NV6Qa5U39L6GINA/CLnhK 5rxWAlUq1mzF1QOyr25CRZ9xgtfhfTjsTRDdTj/Vpzcov9P6uxW6QwXyKqlMkGB98+ +AwBHkPg9OEfH2hp9PgSFTcbft6QXlHY9VBA5dSdyL/d6Isx0epzpjZWG4OsUy3Mo6 85PlG/J2koJnnox/C0P8MSmev3EqCeFXDO8Pz7Rwai2ATcKLN5fwJv6D+I8HgjAGpK N7yoy55VwqahrEXkDKCjW65qR7dnFVGMNCcW7iltxbQ8MzvIzic8l8J4dMEvnk+q7h DhFZd0GNxVJ8g== Date: Tue, 31 Aug 2021 10:47:11 -0500 From: Bjorn Helgaas To: Rob Herring Cc: Chuanjia Liu , Bjorn Helgaas , Matthias Brugger , Lorenzo Pieralisi , Ryder Lee , Jianjun Wang , Yong Wu , PCI , "moderated list:ARM/Mediatek SoC support" , devicetree@vger.kernel.org, linux-arm-kernel , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v12 2/6] PCI: mediatek: Add new method to get shared pcie-cfg base address Message-ID: <20210831154711.GA107126@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 31, 2021 at 10:04:40AM -0500, Rob Herring wrote: > On Fri, Aug 27, 2021 at 11:46 AM Bjorn Helgaas wrote: > > > > On Mon, Aug 23, 2021 at 11:27:56AM +0800, Chuanjia Liu wrote: > > > For the new dts format, add a new method to get > > > shared pcie-cfg base address and use it to configure > > > the PCIECFG controller > > > > Rewrap this to fill 75 columns. > > > > > Signed-off-by: Chuanjia Liu > > > Acked-by: Ryder Lee > > > --- > > > drivers/pci/controller/pcie-mediatek.c | 17 +++++++++++++++++ > > > 1 file changed, 17 insertions(+) > > > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c > > > index 25bee693834f..4296d9e04240 100644 > > > --- a/drivers/pci/controller/pcie-mediatek.c > > > +++ b/drivers/pci/controller/pcie-mediatek.c > > > @@ -14,6 +14,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -23,6 +24,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > #include > > > > > > #include "../pci.h" > > > @@ -207,6 +209,7 @@ struct mtk_pcie_port { > > > * struct mtk_pcie - PCIe host information > > > * @dev: pointer to PCIe device > > > * @base: IO mapped register base > > > + * @cfg: IO mapped register map for PCIe config > > > * @free_ck: free-run reference clock > > > * @mem: non-prefetchable memory resource > > > * @ports: pointer to PCIe port information > > > @@ -215,6 +218,7 @@ struct mtk_pcie_port { > > > struct mtk_pcie { > > > struct device *dev; > > > void __iomem *base; > > > + struct regmap *cfg; > > > struct clk *free_ck; > > > > > > struct list_head ports; > > > @@ -682,6 +686,10 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port) > > > val |= PCIE_CSR_LTSSM_EN(port->slot) | > > > PCIE_CSR_ASPM_L1_EN(port->slot); > > > writel(val, pcie->base + PCIE_SYS_CFG_V2); > > > + } else if (pcie->cfg) { > > > + val = PCIE_CSR_LTSSM_EN(port->slot) | > > > + PCIE_CSR_ASPM_L1_EN(port->slot); > > > + regmap_update_bits(pcie->cfg, PCIE_SYS_CFG_V2, val, val); > > > } > > > > > > /* Assert all reset signals */ > > > @@ -985,6 +993,7 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie) > > > struct device *dev = pcie->dev; > > > struct platform_device *pdev = to_platform_device(dev); > > > struct resource *regs; > > > + struct device_node *cfg_node; > > > int err; > > > > > > /* get shared registers, which are optional */ > > > @@ -995,6 +1004,14 @@ static int mtk_pcie_subsys_powerup(struct mtk_pcie *pcie) > > > return PTR_ERR(pcie->base); > > > } > > > > > > + cfg_node = of_find_compatible_node(NULL, NULL, > > > + "mediatek,generic-pciecfg"); > > > > This looks wrong to me. IIUC, since we start at NULL, this searches > > the entire device tree for any node with > > > > compatible = "mediatek,generic-pciecfg" > > > > but we should only care about the specific device/node this driver > > claimed. > > > > Should this be part of the match data, i.e., struct mtk_pcie_soc? > > What would you put in match data exactly? > > The other way to do this is to have a DT property with the phandle > which people like to do (have everything in the node 'for their > driver'). If there's only 1 possible node (which is almost always the > case), then there is little benefit to having another property. It's > just redundant data. A phandle lookup might be a bit faster with the > caching we do, but on a miss it would still walk all nodes. > > The other thing with these 'extra register bits to twiddle' is that > they tend to be SoC specific and change from chip to chip, so either > way is not very portable. The real question to ask is should there be > a standard interface used or created. > > > > + if (cfg_node) { > > > + pcie->cfg = syscon_node_to_regmap(cfg_node); > > > > Other drivers in drivers/pci/controller/ use > > syscon_regmap_lookup_by_phandle() (j721e, dra7xx, keystone, > > layerscape, artpec6) or syscon_regmap_lookup_by_compatible() (imx6, > > kirin, v3-semi). > > There's no phandle to use in this case. As above, I'm trying to break > people of this habit. Thanks! I was mistaken in lots of ways here. I first assumed "mediatek,generic-pciecfg" was local to the pcie node, but that's not true. Then I thought there might be an ownership issue because the regmap is not local to the device, and several drivers look up and use the same regmap. But it looks like regmap provides some internal locking which mitigates most or all of that concern. Just to check -- you prefer syscon_regmap_lookup_by_compatible() over syscon_regmap_lookup_by_phandle()?