From: Rob Herring <robh+dt@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Chuanjia Liu <chuanjia.liu@mediatek.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Ryder Lee <ryder.lee@mediatek.com>,
Jianjun Wang <jianjun.wang@mediatek.com>,
Yong Wu <yong.wu@mediatek.com>, PCI <linux-pci@vger.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
devicetree@vger.kernel.org,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v12 2/6] PCI: mediatek: Add new method to get shared pcie-cfg base address
Date: Tue, 31 Aug 2021 13:24:09 -0500 [thread overview]
Message-ID: <CAL_Jsq+y=-UTv6B5cGG5p-q-rzzyEuWZ_Q6YKPT=Jej1boZwjQ@mail.gmail.com> (raw)
In-Reply-To: <20210831154711.GA107126@bjorn-Precision-5520>
On Tue, Aug 31, 2021 at 10:47 AM Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> On Tue, Aug 31, 2021 at 10:04:40AM -0500, Rob Herring wrote:
> > On Fri, Aug 27, 2021 at 11:46 AM Bjorn Helgaas <helgaas@kernel.org> 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 <chuanjia.liu@mediatek.com>
> > > > Acked-by: Ryder Lee <ryder.lee@mediatek.com>
> > > > ---
> > > > 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 <linux/irqchip/chained_irq.h>
> > > > #include <linux/irqdomain.h>
> > > > #include <linux/kernel.h>
> > > > +#include <linux/mfd/syscon.h>
> > > > #include <linux/msi.h>
> > > > #include <linux/module.h>
> > > > #include <linux/of_address.h>
> > > > @@ -23,6 +24,7 @@
> > > > #include <linux/phy/phy.h>
> > > > #include <linux/platform_device.h>
> > > > #include <linux/pm_runtime.h>
> > > > +#include <linux/regmap.h>
> > > > #include <linux/reset.h>
> > > >
> > > > #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()?
Yes, unless there is either more than 1 instance of the syscon or some
additional data specific to the user (e.g. a register offset).
Rob
next prev parent reply other threads:[~2021-08-31 18:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-23 3:27 [PATCH v12 0/6] PCI: mediatek: Spilt PCIe node to comply with hardware design Chuanjia Liu
2021-08-23 3:27 ` [PATCH v12 1/6] dt-bindings: PCI: mediatek: Update the Device tree bindings Chuanjia Liu
2021-08-23 3:27 ` [PATCH v12 2/6] PCI: mediatek: Add new method to get shared pcie-cfg base address Chuanjia Liu
2021-08-27 16:46 ` Bjorn Helgaas
2021-08-30 7:09 ` Chuanjia Liu
2021-08-30 21:43 ` Bjorn Helgaas
2021-08-31 3:31 ` Chuanjia Liu
2021-08-31 15:17 ` Rob Herring
2021-09-02 9:34 ` Chuanjia Liu
2021-08-31 15:04 ` Rob Herring
2021-08-31 15:47 ` Bjorn Helgaas
2021-08-31 18:24 ` Rob Herring [this message]
2021-08-23 3:27 ` [PATCH v12 3/6] PCI: mediatek: Add new method to get irq number Chuanjia Liu
2021-08-31 18:30 ` Bjorn Helgaas
2021-09-02 9:28 ` Chuanjia Liu
2021-08-23 3:27 ` [PATCH v12 4/6] PCI: mediatek: Get pci domain and decide how to parse node Chuanjia Liu
2021-08-23 3:27 ` [PATCH v12 5/6] arm64: dts: mediatek: Split PCIe node for MT2712 and MT7622 Chuanjia Liu
2021-09-21 18:43 ` Matthias Brugger
2021-08-23 3:28 ` [PATCH v12 6/6] ARM: dts: mediatek: Update MT7629 PCIe node for new format Chuanjia Liu
2021-09-21 18:43 ` Matthias Brugger
2021-08-26 12:53 ` [PATCH v12 0/6] PCI: mediatek: Spilt PCIe node to comply with hardware design Lorenzo Pieralisi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_Jsq+y=-UTv6B5cGG5p-q-rzzyEuWZ_Q6YKPT=Jej1boZwjQ@mail.gmail.com' \
--to=robh+dt@kernel.org \
--cc=bhelgaas@google.com \
--cc=chuanjia.liu@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=helgaas@kernel.org \
--cc=jianjun.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=ryder.lee@mediatek.com \
--cc=yong.wu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).