Re: [PATCH v3 02/23] gcc-sdm845: Add rates to the GP clocks

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

 



Why cannot max values be defined as ((2 ^ mnd_width) - 1) and ((2 ^
hid_width) - 1)?

вт, 18 июн. 2024 г. в 22:12, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>:
>
>
>
> 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)
>
> Konrad





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux