Re: [PATCH 2/8] phy: Introduce Qualcomm ethernet uniphy driver

[Andrew Lunn]

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