On Tue, Jun 18, 2024 at 09:11:58PM GMT, Konrad Dybcio wrote: > > > On 6/18/24 20:55, Dmitry Baryshkov wrote: > > On Tue, Jun 18, 2024 at 08:50:52PM GMT, Konrad Dybcio wrote: > > > > > > > > > On 6/18/24 19:50, Dmitry Baryshkov wrote: > > > > On Tue, Jun 18, 2024 at 04:59:36PM GMT, Dzmitry Sankouski wrote: > > > > > sdm845 has "General Purpose" clocks that can be muxed to > > > > > SoC pins. > > > > > > > > > > Those clocks may be used as e.g. PWM sources for external peripherals. > > > > > Add more frequencies to the table for those clocks so it's possible > > > > > for arbitrary peripherals to make use of them. > > > > > > > > > > See also: bf8bb8eaccf(clk: qcom: gcc-msm8916: Add rates to the GP > > > > > clocks) > > > > > > > > Each time I look at the table attached to the GP CLK, I feel that it's > > > > plain wrong. In the end the GPCLK can in theory have arbitrary value > > > > depending on the usecase. > > > > > > > > Bjorn, Konrad, maybe we should add special clk_ops for GP CLK which > > > > allow more flexibility than a default clk_rcg2_ops? > > > > > > If we can somehow get max m/n/d values for all possible parents, sure > > > > Calculate them at runtime? > > We'd be calculating the mnd values for a frequency that's either equal or > reasonably close to the one requested. My worry is that we somehow need > to get the maximum values they can take (unless they're well-known)
One of the options might be to force devices to use assigned-clock-parent to set GP CLK sorource and pwm-clk as an actual device using the clock. -- With best wishes Dmitry
