Quoting Jie Luo (2023-09-08 04:10:35) > > > Yes, the uniphy implements the clock provider that supports changing > rate, which will be upstream later, and nss_cc_mac5_rx_clk_src is the > special case, which is only used in the switch device qca8386. Ok great. > > For the phy device qca8084(uniphy has only 312.5M fix clock which is > registered by device tree), this clock nss_cc_mac5_rx_clk_src is not used. > > The issue for the switch device(qca8386) here is the clock rate of > parent uniphy can't be changed because of the clock rate requirement of > branch clock, since the uniphy clock rate is decided by the current > working interface mode(PHY_INTERFACE_MODE_2500BASEX with 312.5M or > PHY_INTERFACE_MODE_SGMII with 125M). Got it. > > For example, when the uniphy works on PHY_INTERFACE_MODE_2500BASEX, then > the parent uniphy clock rate is 312.5M, which is decided by hardware and > can't be changed. when a branch clock requires a 25M clock, the parent > uniphy clock maybe updated to 125M by clock framework if the flag > CLK_SET_RATE_PARENT is set here, but the actual hardware clock rate of > uniphy is still 315.5M since the uniphy still works in the interface > mode PHY_INTERFACE_MODE_2500BASEX. > If the parent rate can't change because CLK_SET_RATE_PARENT is missing and the hardware doesn't allow it, then perhaps instead of having a frequency table we should have rcg clk ops for determine_rate that simply looks at the parent rates and finds the rate closest to what is desired. And for the set_rate clk_op we can have it be simple and just program a fixed divider. The benefit is less frequency tables that don't do anything and less hard-coding of the frequency. I thought we already had those rcg clk_ops but I couldn't find them with a quick glance.
