Hi Geert Uytterhoeven,
Thanks for the feedback.
> Subject: Re: [PATCH RFC 1/3] dt-bindings: clock: Add Renesas versa3 clock
> generator bindings
>
> Hi Biju,
>
> On Thu, Mar 9, 2023 at 10:44 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@xxxxxxxxxx> wrote:
> > On 09/03/2023 10:18, Biju Das wrote:
> > >> -----Original Message-----
> > >> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> On
> > >> 09/03/2023 08:57, Biju Das wrote:
> > >>>>> It is clk generator HW specific. Clk generator is vital
> > >>>>> component which provides clocks to the system.
> > >>>>
> > >>>> Every clock controller is vital...
> > >>>>
> > >>>>> We are providing some hardware feature which is exposed as dt
> > >>>>> properties.
> > >>>>>
> > >>>>> Like clock output is fixed rate clock or dynamic rate clock/
> > >>>>
> > >>>> OK, I wait then for proper description which will explain and
> > >>>> justify
> > >> this.
> > >>>
> > >>> Here it is, Please let me know is it ok?
> > >>>
> > >>> renesas,output-clock-fixed-rate-mode:
> > >>> type: boolean
> > >>> description:
> > >>> In output clock fixed rate mode, the output clock frequency
> > >>> is
> > >> always
> > >>> fixed and the hardware will use the values from the OTP or
> > >>> full
> > >> register
> > >>> map initialized during boot.
> > >>> If not given, the output clock rate is not fixed.
> > >>> maxItems: 6
> > >>
> > >> boolean is scalar, not array, so no maxItems. If the frequency is
> > >> taken from OTP or register map, why they cannot also provide
> > >> information the clock is fixed?
> > >
> > > OK, I will make an array property instead. From HW perspective each
> > > clock output from the Clock generator is controllable ie, fixed rate or
> dynamic rate.
> > >
> > > If all the output clocks are fixed rate one, then frequency is taken
> > > from OTP or register map. But if any one clock output generates
> > > dynamic rate, then it uses dynamic settings.
> >
> > Second try, same question, let me know if it is not clear:
> >
> > "why they cannot also provide information the clock is fixed?"
>
> What is the actual use case?
> My understanding is:
> 1. If the OTP is programmed, the clock generator will be configured
> from the OTP on power-on,
Correct.
> 2. The clock generator can be (re)configured from software.
> a. If the OTP is programmed, this is not needed,
Yes, But we miss some HW functionality.
Eg:
On RZ/G2L SMARC EVK, By default audio mclk is connected to
11.2896 MHz clk (se2 output from clock generator) which is multiple of 44.1KHz.
and this clock is a non-critical clock.
48Khz playback/record is not possible with Audio codec, if we just use the
value from OTP.
But by changing parent of "se2 clock", it is possible to achieve
48 KHz playback.
> b. For critical clocks, you may want to prevent this.
For caseb, Critical clocks we won't change its registers.
The reconfiguration is only for non-critical clocks.
> Also, AFAIUI, "fixed frequency" or "dynamic frequency" is a policy, and
> purely software? Or are there OTP bits to enforce this?
Nothing OTP bits related.
>
> Perhaps you need a per-output "do-not-change-frequency" flag, probably with
> a generic name, in the spirit of "regulator-always-on"
> for regulators?
Yes "do-not-change-frequency" flag for per-output is sensible one.
> Now, if all the output clocks are fixed rate, you might want to describe
> this in DTS using a set of fixed{,-factor-}-clocks?
On Ideal case, all the output clocks are fixed rate and use the value from OTP.
But cases like, non critical clocks we should be able to
change frequency of that particular clock output.
In audio playback case, it is just 1 bit for changing the parent,
After the initial reconfiguration.
Cheers,
Biju
