From: Arnd Bergmann <arnd@arndb.de> To: Lian Minghuan-B31939 <B31939@freescale.com> Cc: "Minghuan.Lian@freescale.com" <Minghuan.Lian@freescale.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>, "Mingkai.Hu@freescale.com" <Mingkai.Hu@freescale.com>, Roy Zang <tie-fei.zang@freescale.com> Subject: Re: 答复: [PATCH 2/2] PCI: Layerscape: Add Layerscape PCIe driver Date: Tue, 09 Sep 2014 11:56:11 +0200 [thread overview] Message-ID: <6844751.zBSvS2zU47@wuerfel> (raw) In-Reply-To: <540F3825.6080601@freescale.com> On Tuesday 09 September 2014 17:25:57 Lian Minghuan-B31939 wrote: > On 2014年09月05日 08:44, Arnd Bergmann wrote: > > On Friday 05 September 2014 07:22:08 Minghuan.Lian@freescale.com wrote: > >>> +struct ls_pcie { > >>> + struct list_head node; > >>> + struct device *dev; > >>> + struct pci_bus *bus; > >>> + void __iomem *dbi; > >>> + void __iomem *scfg; > >>> + struct pcie_port pp; > >>> + int id; > >>> + int index; > >>> + int irq; > >>> + int msi_irq; > >>> + int pme_irq; > >>> +}; > >> irq and pme_irq seem to be completely unused, so better > >> not add them until they are actually used. > >> [Minghuan] Ok, I will remove them. > >> > >> The scfg registers seem to belong to another device that > >> is responsible for multiple instances. Unfortunately, > >> this "fsl,ls1021a-scfg" device is not documented anywhere > >> that I can see. > >> > >> Is this some sort of syscon node, or is it specific to the > >> pcie controller(s)? > >> > >> [Minghaun] SCFG provides SoC specific configuration and status > >> registers for the device including PCI USB eTSEC SATA ... > >> The platform patches that contains SCFG code are being upstream. > > This sounds like it should be a syscon node, and you should use > > syscon_regmap_lookup_by_phandle() to find the scfg node from each > > of those drivers, rather than scanning the DT yourself in each > > of the drivers using it. > > > > This can also be a place to put the index, such as > > > > scfg = <&scfg 0>; > > > > for the first PCIe node. The probe function then extracts both > > the phandle for the syscon and the index from that property. > [Minghuan] I discussed with my colleague. They worry about performance > degradation if using regmap API, > because there are some fast device use scfg. We tend to use a simple way > to map andread/write scfg directly. I see. In this case, I would probably create a separate msi controller driver that owns the "fsl,ls1021a-scfg" device, and is referenced through the "msi-parent" property in the pcie controller. You can use of_pci_find_msi_chip_by_node() to get the msi_chip instance and then connect that to your pci host. This will also take care of the case where you may want to use the main GICv3 on a future SoC. > >>> +static int ls_pcie_link_up(struct pcie_port *pp) > >>> +{ > >>> + u32 rc, tmp; > >>> + struct ls_pcie *pcie = to_ls_pcie(pp); > >>> + > >>> + tmp = ioread32(pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + iowrite32(SCFG_NO_BIT_REVERSE, pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + > >>> + rc = (ioread32(pcie->scfg + PEXMSCPORTSR(pcie->index)) >> > >>> + LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK; > >>> + > >>> + iowrite32(tmp, pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + > >>> + if (rc < LTSSM_PCIE_L0) > >>> + return 0; > >>> + > >>> + return 1; > >>> +} > >> This looks like it is really a phy driver, although a pretty minimal > >> one. > >> > >> [Minghuan] I read SCFG register. SCFG provides SoC specific configuration > >> and status registers for the device including PCI USB eTSEC SATA ... > > I'm guessing that a lot of that is phy related information though. > > A nicer way to deal with this, compared to using syscon directly is > > to have a phy driver for your chip, and have that deal with all > > the phy related setup. In this case you would have a reference in > > the client driver like > > > > phys = <&scfgphy LS1021A_PHY_PCIE0>; > > phy-names = "pcie"; > > > > And in the pcie driver you just call devm_phy_get(dev, "pcie") to get a reference > > to that phy node, and then you can use the phy API to perform actions on > > it (init, power_on, power_off, exit). > > > > This keeps all knowledge about the phy registers inside of the scfg area > > in one place, and you only have to add a new phy driver for a future SoC > > that has the same PCIe core but different scfg. > [Minghuan] SCFG does not contains power_on power_off or other PCI > control registers. > We only get link up and MSI related status via SCFG. So I think it is > not enough to call scfg PCIe phy. Ok, then use syscon for this one. Note that we are currently changing the syscon code to make it easier for the same device to be both syscon and driven by another device driver such as the msi_chip above. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: 答复: [PATCH 2/2] PCI: Layerscape: Add Layerscape PCIe driver Date: Tue, 09 Sep 2014 11:56:11 +0200 [thread overview] Message-ID: <6844751.zBSvS2zU47@wuerfel> (raw) In-Reply-To: <540F3825.6080601@freescale.com> On Tuesday 09 September 2014 17:25:57 Lian Minghuan-B31939 wrote: > On 2014?09?05? 08:44, Arnd Bergmann wrote: > > On Friday 05 September 2014 07:22:08 Minghuan.Lian at freescale.com wrote: > >>> +struct ls_pcie { > >>> + struct list_head node; > >>> + struct device *dev; > >>> + struct pci_bus *bus; > >>> + void __iomem *dbi; > >>> + void __iomem *scfg; > >>> + struct pcie_port pp; > >>> + int id; > >>> + int index; > >>> + int irq; > >>> + int msi_irq; > >>> + int pme_irq; > >>> +}; > >> irq and pme_irq seem to be completely unused, so better > >> not add them until they are actually used. > >> [Minghuan] Ok, I will remove them. > >> > >> The scfg registers seem to belong to another device that > >> is responsible for multiple instances. Unfortunately, > >> this "fsl,ls1021a-scfg" device is not documented anywhere > >> that I can see. > >> > >> Is this some sort of syscon node, or is it specific to the > >> pcie controller(s)? > >> > >> [Minghaun] SCFG provides SoC specific configuration and status > >> registers for the device including PCI USB eTSEC SATA ... > >> The platform patches that contains SCFG code are being upstream. > > This sounds like it should be a syscon node, and you should use > > syscon_regmap_lookup_by_phandle() to find the scfg node from each > > of those drivers, rather than scanning the DT yourself in each > > of the drivers using it. > > > > This can also be a place to put the index, such as > > > > scfg = <&scfg 0>; > > > > for the first PCIe node. The probe function then extracts both > > the phandle for the syscon and the index from that property. > [Minghuan] I discussed with my colleague. They worry about performance > degradation if using regmap API, > because there are some fast device use scfg. We tend to use a simple way > to map andread/write scfg directly. I see. In this case, I would probably create a separate msi controller driver that owns the "fsl,ls1021a-scfg" device, and is referenced through the "msi-parent" property in the pcie controller. You can use of_pci_find_msi_chip_by_node() to get the msi_chip instance and then connect that to your pci host. This will also take care of the case where you may want to use the main GICv3 on a future SoC. > >>> +static int ls_pcie_link_up(struct pcie_port *pp) > >>> +{ > >>> + u32 rc, tmp; > >>> + struct ls_pcie *pcie = to_ls_pcie(pp); > >>> + > >>> + tmp = ioread32(pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + iowrite32(SCFG_NO_BIT_REVERSE, pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + > >>> + rc = (ioread32(pcie->scfg + PEXMSCPORTSR(pcie->index)) >> > >>> + LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK; > >>> + > >>> + iowrite32(tmp, pcie->scfg + SCFG_SCFGREVCR_OFF); > >>> + > >>> + if (rc < LTSSM_PCIE_L0) > >>> + return 0; > >>> + > >>> + return 1; > >>> +} > >> This looks like it is really a phy driver, although a pretty minimal > >> one. > >> > >> [Minghuan] I read SCFG register. SCFG provides SoC specific configuration > >> and status registers for the device including PCI USB eTSEC SATA ... > > I'm guessing that a lot of that is phy related information though. > > A nicer way to deal with this, compared to using syscon directly is > > to have a phy driver for your chip, and have that deal with all > > the phy related setup. In this case you would have a reference in > > the client driver like > > > > phys = <&scfgphy LS1021A_PHY_PCIE0>; > > phy-names = "pcie"; > > > > And in the pcie driver you just call devm_phy_get(dev, "pcie") to get a reference > > to that phy node, and then you can use the phy API to perform actions on > > it (init, power_on, power_off, exit). > > > > This keeps all knowledge about the phy registers inside of the scfg area > > in one place, and you only have to add a new phy driver for a future SoC > > that has the same PCIe core but different scfg. > [Minghuan] SCFG does not contains power_on power_off or other PCI > control registers. > We only get link up and MSI related status via SCFG. So I think it is > not enough to call scfg PCIe phy. Ok, then use syscon for this one. Note that we are currently changing the syscon code to make it easier for the same device to be both syscon and driven by another device driver such as the msi_chip above. Arnd
next prev parent reply other threads:[~2014-09-09 9:56 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2014-09-04 18:45 [PATCH 1/2] PCI: designware: change MSI-related pcie_host_ops Minghuan Lian 2014-09-04 18:45 ` Minghuan Lian 2014-09-04 13:20 ` Bjorn Helgaas 2014-09-04 13:20 ` Bjorn Helgaas 2014-09-05 6:15 ` 答复: " Minghuan.Lian at freescale.com 2014-09-04 18:45 ` [PATCH 2/2] PCI: Layerscape: Add Layerscape PCIe driver Minghuan Lian 2014-09-04 18:45 ` Minghuan Lian 2014-09-04 12:14 ` Arnd Bergmann 2014-09-04 12:14 ` Arnd Bergmann 2014-09-04 13:51 ` Arnd Bergmann 2014-09-04 13:51 ` Arnd Bergmann 2014-09-04 13:57 ` Arnd Bergmann 2014-09-04 13:57 ` Arnd Bergmann 2014-09-05 7:22 ` 答复: " Minghuan.Lian at freescale.com 2014-09-05 8:44 ` Arnd Bergmann 2014-09-05 8:44 ` Arnd Bergmann 2014-09-09 17:25 ` Lian Minghuan-B31939 2014-09-09 17:25 ` Lian Minghuan-B31939 2014-09-09 9:56 ` Arnd Bergmann [this message] 2014-09-09 9:56 ` Arnd Bergmann 2014-09-09 18:46 ` Lian Minghuan-B31939 2014-09-09 18:46 ` Lian Minghuan-B31939 2014-09-09 10:50 ` Arnd Bergmann 2014-09-09 10:50 ` Arnd Bergmann 2014-09-09 19:16 ` Lian Minghuan-B31939 2014-09-09 19:16 ` Lian Minghuan-B31939 2014-09-09 11:58 ` Arnd Bergmann 2014-09-09 11:58 ` Arnd Bergmann 2014-09-10 11:29 ` Lian Minghuan-B31939 2014-09-10 11:29 ` Lian Minghuan-B31939 2014-09-04 13:24 ` Bjorn Helgaas 2014-09-04 13:24 ` Bjorn Helgaas 2014-09-05 7:24 ` 答复: " Minghuan.Lian at freescale.com 2014-09-04 20:21 ` Fabio Estevam 2014-09-04 20:21 ` Fabio Estevam 2014-09-04 21:12 ` Arnd Bergmann 2014-09-04 21:12 ` Arnd Bergmann 2014-09-05 6:43 ` 答复: " Minghuan.Lian at freescale.com 2014-09-05 7:40 ` Minghuan.Lian at freescale.com
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=6844751.zBSvS2zU47@wuerfel \ --to=arnd@arndb.de \ --cc=B31939@freescale.com \ --cc=Minghuan.Lian@freescale.com \ --cc=Mingkai.Hu@freescale.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-pci@vger.kernel.org \ --cc=tie-fei.zang@freescale.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.