Messages in this thread |  | | Date | Wed, 24 Jan 2024 00:25:07 +0100 | | From | Andrew Lunn <> | | Subject | Re: [PATCH 2/8] phy: Introduce Qualcomm ethernet uniphy driver |
| |
On Tue, Jan 23, 2024 at 11:58:26PM +0800, Ziyang Huang wrote: > 在 2024/1/21 20:42, Ziyang Huang 写道: > > +#define rmwl(addr, mask, val) \ > > + writel(((readl(addr) & ~(mask)) | ((val) & (mask))), addr) > > + > > +static int cmn_init(struct platform_device *pdev) > > +{ > > + struct resource *res; > > + void __iomem *cmn_base; > > + void __iomem *tcsr_base; > > + u32 val; > > + > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cmn"); > > + if (!res) > > + return 0; > > + > > + cmn_base = devm_ioremap_resource(&pdev->dev, res); > > + if (IS_ERR_OR_NULL(cmn_base)) > > + return PTR_ERR(cmn_base); > > + > > + /* For IPQ50xx, tcsr is necessary to enable cmn block */ > > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "tcsr"); > > + if (res) { > > + tcsr_base = devm_ioremap_resource(&pdev->dev, res); > > + if (IS_ERR_OR_NULL(tcsr_base)) > > + return PTR_ERR(tcsr_base); > > + > > + rmwl((tcsr_base + TCSR_ETH_CMN), TCSR_ETH_CMN_ENABLE, > > + TCSR_ETH_CMN_ENABLE); > > + } > > + > > + rmwl((cmn_base + CMN_PLL_REFCLK_SRC), > > + CMN_PLL_REFCLK_SRC_FROM_MASK, > > + CMN_PLL_REFCLK_SRC_FROM_REG); > > + rmwl((cmn_base + CMN_PLL_REFCLK), > > + (CMN_PLL_REFCLK_EXTERNAL | CMN_PLL_REFCLK_FREQ_MASK > > + | CMN_PLL_REFCLK_DIV_MASK), > > + (CMN_PLL_REFCLK_FREQ_48M | CMN_PLL_REFCLK_DIV(2))); > > + > > + rmwl((cmn_base + CMN_PLL_CTRL), CMN_PLL_CTRL_RST_N, 0); > > + msleep(1); > > + rmwl((cmn_base + CMN_PLL_CTRL), CMN_PLL_CTRL_RST_N, > > + CMN_PLL_CTRL_RST_N); > > + msleep(1); > > + > > + return read_poll_timeout(readl, val, > > + (val & CMN_PLL_STATUS_LOCKED), > > + 100, 200000, false, > > + (cmn_base + CMN_PLL_STATUS)); > > +} > > + > > Hi Andrew, > > Sorry to bother you. But I can't make a decision here. > > The CMN block (Seem like the Abbreviation of "component") controls the > entire network block. It need to be configured before uniphy, mdio, gmac, > etc.. In the past, Qualcomm put it in mdio driver. But UNIPHY need to been > initializated before mdio because some PHYs/switchs use the outclk provided > by UNIPHY as their main clocks. > > So it seem like that it should be described in a separate node. But I > couldn't find a suitable driver directory for it. Can you please give me > some suggestions? Thanks.
Maybe drivers/soc/qcom.
Does it provide any resources to the uniphy, mdio, gmac, etc? Anything which can be used to link all the bits together?
Looking at CMN_PLL_CTRL_RST_N, could it be considered as a reset driver? Each of the other drivers have a phandle to it, and use the reset API to take it out of reset when they probe? That should give you some ordering guarantees.
Andrew
|  |