Quoting Jie Luo (2023-09-12 05:07:02) > > > On 9/12/2023 4:11 AM, Stephen Boyd wrote: > > Quoting Jie Luo (2023-09-08 04:10:35) > >> > >> 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. > > Thanks Stephen for the suggestion. > looks you are saying the clk ops clk_dp_ops for the fix parent rate? > which seems not meet the clock requirement of this clock. Yeah that is close, but the determine_rate clk_op needs to look at all possible parents. With the dp clk_ops we assume that only one parent is possible. > > For the device qca8k, it is also possible to switch the interface modes > between PHY_INTERFACE_MODE_2500BASEX(312.5M) and > PHY_INTERFACE_MODE_SGMII(125M) during the running time, and there are > multiple parent clock source(P_UNIPHY0_RX or P_UNIPHY0_TX) for the RCG > clocks to select according to the current work mode. so the parent_map > and freq_tbl are necessary to this clock. I still don't see why the freq_tbl is necessary.
