Re: [PATCH v6 4/4] clk: qcom: add clock controller driver for qca8386/qca8084

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 9/13/2023 1:18 AM, Stephen Boyd wrote:
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.

Hi Stephen,
For clk_rcg2_ops, freq_tbl is used to find the closest rate to decided the parent clock, the configuration of clock source and clock divider are saved in the freq_tbl to configure the RCG hardware register, the mapping of parent clock and hardware register value is decided by the freq_tbl for the RCG clock.



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux